My application to fly.io

Posted on:
3 min

This is an exercise in product thinking and user experience. You’re not going to write any code, and you should spend maximum 10 minutes on it. Pretend Fly.io doesn’t show you anything for logs and metrics, and we decided today that we’re going to build that into our Dashboard. Customers have been asking for this. We know there are a tremendous number of developers who will benefit from some flavor of minimal, important logs and metrics, and that’s who we’re serving. We’re not talking about shipping logs to another provider or integrating APM. We are talking about streaming logs and letting users see the most important data about their apps that we’re already collecting in Prometheus. We have people here who can do the plumbing work to get whatever we need going, we don’t expect you to build that stuff (but you will be working with those folks). Your job is to make the product something most people can use directly in the dashboard. Please reply to this email and share your 🔥 hot takes 🔥 to these three questions: 1. What users should we focus on? 2. What do you think these users want to be able to see and do in a logs or metrics UI?3. How did you get there? What’s your thought process? Again, please spend maximum 10 minutes on this. We care about your ability to make decisions on behalf of users, and we want to see your thought process. We just want to see the early notes version (again, just your hot takes! Be bold!) of what you’d think about. Don’t worry about whether or not we might disagree with your takes; what’s most important is for us to see your decision-making process. (In fact, we LIKE to read bold ideas that we disagree with, when we can see your thought process!)

  1. Fly is a developer-focused CLI-driven platform. Logs provide richer feedback which leads to faster iteration which I imagine matters a lot to Fly’s median userbase. I will prioritize logs over metrics. The developers that have started using the platform and are still figuring out how their vibe-coded application works on it are the users to focus on.
  2. The tail of logs and filtering is the obvious use case for monitoring and debugging (using properties like host, path/endpoint, return code, referrer, and userId). I want to separate application logs from platform logs visually, using contrast or space. The user can use group-by aggregate COUNT (*) WHERE expr to analyze patterns like usage per account and usage per endpoint. While most APMs create filtering interfaces for some use cases and allow the rest to be hand written using SQL-like languages, I think it is possible to write a functional user interface that supports group-by’s, filters, and aggregation without having to switch contexts. The data table in Notion is a good example of this. I would also ensure that the table state is represented in the URL and shareable because it really matters for rapid traceable incident management and debugging.
  3. Developers of mature applications find metrics useful for things like alerting and SLO’s, which aren’t really useful until the application works at all. Since the target users are in their early phase of using the platform, and presumably also in the early phases of their software being built, I want to focus on giving them the ability to get started with the platform, fast. Paginated tables with filtering capabilities for logs are well understood patterns for most users on the internet and will be low friction for users and the team that develops it.

My friend itihas thinks my takes aren’t hot enough, so here are 3 more sarcastic takes that are hotter but less practical

  1. Logs are for script-kiddies who can’t get their applications running in the first go. Metrics are the only thing useful to post on Twitter to get VC’s to fund you. We should build metrics first for Twitter-famous tech influencers.
  2. An aesthetic metrics roundup should be as easy to share for the user as it is to share running stats to Instagram from their iPhone. The user’s application performance is only important when it is seen by a manager or a VC. It would also be useful to make a Spotify-wrapped equivalent of metrics over time.
  3. Nothing matters more to a company than views on Twitter. It gets new developers signed up to get themselves the same pretty metric picture on Twitter. It is then the platform’s responsibility to lock them in for profits.