01Meet Chronosphere
Observability at billions of data points a second
Chronosphere is an observability platform for engineering teams that need to find and fix problems fast.
Chronosphere is a cloud-native observability platform built on the open-source M3, for engineering teams that need to find and fix problems fast.
Companies at every stage of their cloud-native journey, from startups to mature orgs with a dedicated Central Observability Team.
Granular control over what data is ingested, which helps manage the observability budget team by team.
02A bold bet, rewound
The north star: GitOps for observability
Our co-founders' bet: a Git process inside Chronosphere. The GitOps team was formed to test it before we built it.
Our co-founders wrote a vision: give users a well-structured Git process inside Chronosphere, and it could solve real pain and become a competitive advantage. The GitOps team was formed to dig in.
- Different entities, different formats. Dashboards were made in the UI, but critical aggregation rules lived in the backend.
- View in the UI, edit in the backend. App developers could see changes, but saving them needed Terraform skills or the central team, with no Git review process.
- Clutter. Abandoned experiments piled up in shared spaces.
- Different needs. Central teams wanted visual feedback; app developers wanted the code.
03Who it's for
Three personas, including the one everyone forgot
Writes and manages observability code and rules. Needs scalable, replicable systems, visual feedback before code ships, and a clear record of what changed, why, when and by whom.
Responds to alerts and tweaks monitors mid-incident. Wants more control with a small blast radius, and a safe sandbox to experiment, then save or discard.
Usually forgotten, but critical to every launch. Wants to demo and customize on the fly, without wrestling with source code.
A customer success insightThey didn't believe Chronosphere should be known for its "Git" features, but saw that a smooth way to collaborate on changes could become a real marketing advantage.
See the persona cards
04Research
One size does not fit all
I tested the vision three ways: inside the company, with clients, and against the industry. One workflow couldn't serve everyone.
I split the research three ways, to test the vision before we built it.
- InternalThe vision doc, our assumptions, technical limits, and each entity's roadmap
- With clientsPre-interview journeys, their observability setup, pain points, and how mature their engineering practices were
- ExternalIndustry standards, and what teams did without a Git process
Every company has a different setup. Every entity has different requirements. Every persona has different needs. One workflow couldn't serve them all.
05The turning point
I put our users on a Git Maturity scale
From click-ops to in-house platforms, every client sat somewhere on this line. Slide along it and see who would want GitOps inside Chronosphere.
Rebuilt from my research board, without company names.
06The call
Keep the patterns, skip the platform
Git-mature teams didn't want a third party owning their version control. Teams new to Git weren't ready for it. So I recommended keeping the patterns and skipping the platform.
Already had Git, pull request reviews and pipelines. They didn't want a third party, even Chronosphere, owning their version control.
Didn't want to touch complex Terraform, and weren't ready for yet another layer of version control.
Don't build the full GitOps platform. Take what users did want, like seeing what changed, comparing versions and reading an entity as code, and turn it into patterns the rest of the product could use. The research I led shaped that decision, and it saved the company engineering time on a platform users wouldn't have adopted.
07Built forward
The patterns that lived on
The research did its job: we retired the platform plan, the GitOps team wound down, and I moved on. The version history and code views I started shipped in public in 2023.
| Pattern from our research | In Chronosphere today, in public |
|---|---|
| What changed, why, when and by whom | Version History, Sep 2023: "users can now view and understand how monitors have evolved over time directly in the product." Chronosphere blog ↗ |
| Compare versions like code | A Git-style diff between revisions, showing who made the change and how. Docs ↗ |
| View in the UI, see it as code | Code config shows an entity as Terraform, Chronoctl or API, with a diff for unsaved edits. Docs ↗ |
The team built and shipped these after I moved on, so I can't claim every pixel. The research and early designs were where they began.