Philosophy
The beliefs behind Sazabi — why observability is a conversation, why everything is a log, and who it is built for.
Sazabi is built on a few opinions about what observability should be. They explain why the product works the way it does, and why it looks different from the dashboard-and-query tools it replaces.
Observability should work for you
The tool does the investigative work. The Sazabi agent queries your data, correlates across it, and explains what it found — instead of leaving you to operate dashboards and learn a query language before you can answer a question.
Conversation is the primary interface
Investigations are conversations, not dashboards you curate ahead of time. Threads are persistent, shareable, and multiplayer, so the work of finding a problem is something your team can follow and pick up.
Everything is a log
One data model. Metrics, traces, and webhook events normalize into logs through a single intake with a single query model, so there is one place to search and one shape to reason about.
Alerts should arrive with answers
An alert should carry the evidence that triggered it. Sazabi opens issues with matching records, queries, and correlated changes so you can evaluate the proposed cause instead of starting from a raw threshold breach.
Pay for outcomes, not bytes
Sazabi meters the usage dimensions listed on the pricing page rather than charging per user. Review those dimensions and your project usage when deciding whether to sample or retain less telemetry.
AI agents are first-class users
Observability is for AI as well as humans. Coding agents investigate production through the same surfaces people use — the CLI, the API, and the MCP server — so the tools your team relies on can see production too.
Observability should be for everyone
Observability should reach everyone in the org, not only the most technical. Because conversation is the interface, you can ask Sazabi from the web dashboard, Slack, or Microsoft Teams without learning a query language first.