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 its investigation. Sazabi opens issues with the evidence and root-cause context already attached, rather than handing you a raw threshold breach to go chase down.
Pay for outcomes, not bytes
Cost should scale with the value Sazabi delivers, not with how much telemetry you send. Ingestion is priced so you never have to sample or ration your own data to control the bill.
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.