How Sazabi works

Sazabi has a small set of concepts you meet in the first hour. Learn these and the rest of the product follows; everything else is taught at the top of its own guide.

​

Principles

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 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 your team can follow the work of finding a problem and pick it up.
• Everything is a log. 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. 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.
• AI agents are first-class users. Coding agents investigate production through the same surfaces people use — the CLI, the API, and the MCP server.
• Observability should be for everyone. Because conversation is the interface, anyone in the organization can ask Sazabi from the web dashboard, Slack, or Microsoft Teams without learning a query language first.

​

Threads

A thread is a conversation between you and the Sazabi agent about your systems. Every investigation is a thread.

• Threads persist, so you can return to one days later and continue.
• Each thread has a visibility: private (only you) or organization (everyone in your organization). New threads are organization-visible by default, and the owner can change it.
• Any organization member who can see a thread can open it and add to it, which makes threads a shared record for incident response and onboarding.

See Threads for starting, sharing, forking, searching, and archiving.

​

The Sazabi agent

The Sazabi agent is what you talk to in a thread. It searches your logs, correlates what it finds, and answers with evidence — and it shows the queries it ran so you can verify its reasoning. Beyond reading your data, it works with:

• Tools — everything the agent can use during an investigation: built-in tools such as log search and code search, tools from MCP connectors, and command-line tools it runs in an isolated sandbox. See Agent tools.
• Memory — durable project knowledge (notes and runbooks) the agent reads and writes across investigations, so what it learns persists. See Use project memory.
• Surfaces — you reach the same agent from the dashboard, Slack and Microsoft Teams, GitHub, Bitbucket, Linear, the CLI, the API, and your own coding agent. See Surfaces below.

​

Surfaces

Sazabi is not a single website you log into. You interact with the same agent, threads, and data across many surfaces — first-party and third-party — and everything stays in sync no matter where you pick it up.

• First-party — the web dashboard, the CLI, and the API.
• Third-party — Slack and Microsoft Teams (talk to the agent from chat); GitHub, Bitbucket, and Linear (mention the agent in a pull request or issue comment, or assign it to a Linear issue); and your own coding agent through the CLI or the MCP server.

A thread you start in the dashboard continues in Slack; a question you ask in a pull request comment shows up on the web. The surface is where you talk to Sazabi; the work lives in one place behind all of them.

​

Log sources and streams

Everything you send is a log: Sazabi treats logs, traces, and metrics as one kind of thing — a record with a timestamp, a severity, a service, a body, and attributes — stored and indexed the same way, which is what lets the agent search all of your telemetry in one place. A log source is a connection that brings one system’s records into Sazabi. You set it up once, and that system’s logs flow in continuously. There are two ways to set one up:

• Native — connect your account. You authorize your account and Sazabi provisions and runs the forwarding for you. Examples: AWS CloudWatch, Google Cloud, Vercel, Sentry.
• Manual — send to an endpoint. You point your platform or application at your log source’s intake URL. Examples: OpenTelemetry, Fluent Bit, Vector, or direct API ingestion.

Both modes can stream logs continuously. Manual describes who configures the sender, not whether you send each log by hand. Logs arrive on log streams — the individual channels of data within a source. Once logs arrive, they live in Sazabi-managed log storage, indexed for the agent’s queries; there is no storage backend to provision. Organizations on BYOC keep log storage in an account they own. See Instrument for the full picture.

​

Issues

An issue is a problem Sazabi is tracking. Instead of static thresholds, the agent detects problems and opens an issue when it finds something worth attention. An issue is like an alert in that it notifies you when something needs attention — but unlike an alert, it arrives already investigated: the agent attaches what happened, why, and the evidence, rather than a threshold breach for you to triage. Issues can notify your team through Slack, email, and other channels. See Issues.

​

Integrations

Sazabi connects to the rest of your stack in several ways — all “integrations” in the broad sense, each with its own catalog and its own job:

• Integrations — organization-level connections to shared services (Slack, GitHub, PagerDuty), owned by the organization and acting under a shared identity. See Integration catalog.
• MCP connectors — tools the agent gains from external services over the Model Context Protocol. See MCP connector catalog.
• Sandbox CLIs — command-line tools the agent runs in its sandbox, connected with credentials you supply. See Sandbox CLIs.
• Connected accounts — your personal vendor accounts, linked so the agent can act as you (with correct attribution). See Connected accounts.
• Log sources — the connections that bring your telemetry in, covered above. See Log source catalog.

​

Organizations and projects

• An organization is your team or company. It owns membership, billing, and organization-scoped settings such as integrations.
• A project lives inside an organization and isolates one application or environment’s telemetry. A common pattern is one project per environment (production, staging).

​

Further reading