The trouble with remembering everything is that someone has to pay for the memory. In a software company, the recollections arrive as metrics, logs and traces: how long a request took, what a server said, which services an order passed through. Each seems sensible enough. Multiply them across a thicket of containers and microservices, however, and prudence begins to resemble a very expensive collecting habit.
- Chronosphere monitors cloud systems and helps engineers investigate failures.
- Its distinguishing pitch is control over the data you keep and pay for.
- Customers include DoorDash, Snap, Robinhood, Affirm and Zillow.
- Palo Alto Networks completed its acquisition in January 2026.
Chronosphere makes software for this predicament. It sells an observability platform, the machinery for seeing what is happening inside a distributed application, and a separate pipeline for collecting and routing telemetry. Its interesting proposition is that good visibility requires judgment about what to retain. An engineer needs enough evidence to understand a failure. A finance department would prefer that evidence not include an eternity of useless chatter.
01 The thing watching Uber broke, too
Before there was Chronosphere, there was a monitoring problem at Uber. As the ride-hailing business expanded, its engineers had to keep track of an increasingly complicated system. The existing Graphite and WhisperDB arrangement struggled. The replacement initially used familiar components, including Cassandra and Elasticsearch. The operational firefighting returned.
The M3 project’s own history describes the next steps with admirable lack of romance: build a database, then fix the query engine, then make ingestion more flexible. Slow queries and out-of-memory failures were obstructing the very work monitoring was supposed to make possible. Infrastructure teams needed fine detail briefly; business teams wanted coarser information over longer periods. One storage policy would not satisfy both. M3 became a system built around those differences.
Martin Mao and Rob Skillington worked on that infrastructure at Uber. In 2019, they founded Chronosphere. The open-source project gave them technology and a community with a recognizable problem. Their commercial opportunity was the work surrounding the technology: making it usable, dependable and somebody else’s operational responsibility.
“We just wanted to build a great open source project that was useful to the community.”
Martin Mao, on the work before the company
The founders’ insight developed beyond keeping a database upright. Mao has described an earlier view of observability as a checklist: metrics, logs, traces. In a conversation with Corey Quinn, he explained that checking those boxes did not necessarily help someone detect a problem, understand its impact and find its cause. That shift from collecting ingredients to answering questions explains much of Chronosphere’s product.
02 A filter with a business model
A metric can become expensive without looking particularly exotic. Add labels for service, region, host and customer, and the combinations proliferate. Engineers call this cardinality. Imagine giving every chair at a dinner party its own ledger, then adding a separate ledger for every guest-chair combination. The bookkeeping soon becomes a more demanding event than dinner.
Chronosphere’s Control Plane lets teams inspect consumption and usage, then change the shape of their telemetry. They can aggregate metrics, remove costly labels, downsample measurements, adjust trace sampling or filter logs. Team quotas give that process an owner and a budget. The point is to make choices before low-value detail settles into an expensive permanent residence. Those controls can be changed without redeploying the application.
Applications emit telemetry.
Inspect, aggregate, sample, route.
Keep useful evidence available.
The company sells managed enterprise software through sales-led contracts. For a buyer, the useful calculation includes storage, infrastructure, migration work and the engineering time spent running a monitoring stack. A reduction in data volume cannot, by itself, tell you the reduction in the invoice. Retention, contract terms and the previous system all matter. The appeal is strongest when those operational costs have become a recurring nuisance rather than an occasional irritation.
03 The dinner test
DoorDash offers a particularly concrete example. Its monitoring system had been losing metrics as it scaled. In a September 2024 customer account, engineer Steven Callister described a framework that had reached 14,000 service level objectives. An SLO is a target for how a service should behave. When service calls fail, the consequences can travel out of the server room: a merchant misses an order, a customer encounters an error, dinner arrives late.
DoorDash automated SLO creation so developers could review and adjust objectives instead of making every one by hand. The resulting discussion was about which interactions were healthy and where attention belonged. The number is interesting because of what the engineers did with it. Fourteen thousand beautifully maintained objectives would be a dubious achievement if nobody could connect them to somebody’s meal.
Other published customer results describe different benefits. Chronosphere reported that Snap reduced data volume by more than half and cut on-call pages by 90%. In an Affirm customer interview, former senior principal engineer Srinivas Krishnan described the service handling a Black Friday load increase of up to ten times. These are customer examples published by the vendor, with different baselines and different measures of success.
04 Plumbing before the picture
The platform’s working surface includes Chronosphere Lens, which discovers services and assembles contextual views of their health. Differential Diagnosis, or DDx, helps compare metrics and traces without requiring the responder to construct every query. SLO management supplies another way to focus attention. These features address the moment when an engineer has evidence but still needs a sensible place to begin.
In January 2024, Chronosphere acquired Calyptia, founded by original creators of the Fluent ecosystem. The resulting Telemetry Pipeline extends control into collection, transformation and routing. A team can redact sensitive fields, standardize records and send them to an appropriate destination while data is still moving. The pipeline can serve systems outside Chronosphere; buying the plumbing does not require buying the whole viewing room.
This gives the company a place in two buying conversations: enterprise observability and telemetry management. Datadog, Dynatrace, Grafana Cloud, New Relic and Elastic offer observability alternatives; Cribl is an alternative in pipelines. Building with Prometheus, OpenTelemetry and Fluent Bit remains another route. Chronosphere’s argument centers on operating at scale while controlling data cost. Open-standard support can ease integration, although migrating dashboards, alerts and team habits still takes work.
05 Billions for the ability to see
Investor interest followed. Chronosphere announced a $115 million Series C extension at a $1.6 billion valuation in January 2023, with GV and Geodesic Capital joining existing investors. By September 2025, it reported more than $160 million in annual recurring revenue. Palo Alto Networks then announced an acquisition agreement for $3.35 billion in cash and replacement equity awards, subject to adjustments.
The transaction closed on January 29, 2026. For a security company, telemetry control has an obvious attraction: security tools also need to collect and interpret large amounts of data. Mao joined Palo Alto Networks as SVP and general manager of observability. The pipeline remained available as a standalone product.
Chronosphere’s July 2026 update reported ARR above $300 million and work connecting its platform to Cortex AgentiX for remediation. ARR measures the recurring revenue run rate; it is not the same as recognized annual revenue. The update also said Chronosphere retained a dedicated observability roadmap. That matters for buyers considering a monitoring product now owned by a security vendor.
06 Teach the investigator what matters
Chronosphere announced AI-Guided Troubleshooting in limited availability in November 2025. Its Temporal Knowledge Graph connects services, infrastructure and telemetry, incorporating changes and human investigation context. Suggestions explain what was examined and ruled out. Investigation Notebooks preserve the work. The intended benefit is a shorter journey from alert to an evidence-backed hypothesis, with engineers able to challenge the guidance.
There is a useful lesson here even for a team that never buys Chronosphere. Start with the questions people need answered. Identify who uses each costly signal. Test aggregation against real investigations. Give teams ownership of consumption, and revisit decisions as applications change. Treat a successful diagnosis as knowledge worth preserving, rather than a conversation destined to vanish into chat history.
That discipline has limits. An unused metric can become valuable during an unfamiliar failure. Dropped records cannot be recovered from a store they never reached. A small system with modest telemetry may not justify an enterprise platform or a substantial migration. These are reasons to test policies against actual needs. The desired result is an engineer finding the decisive clue quickly, with enough evidence left to explain why it matters.
Chronosphere’s enduring question is disarmingly domestic: what are we keeping this for? Ask it of a cupboard and you might reclaim a shelf. Ask it of a distributed system, with care, and you might reclaim both a budget and an engineer’s evening.