Core concepts

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.

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:

• Connect your account. You authorize your account and Sazabi provisions and runs the forwarding for you. Examples: AWS CloudWatch, Google Cloud, Vercel, Sentry.
• 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.

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. 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.

Automations

Beyond answering questions, Sazabi can do work on its own — running checks, watching for events, and opening issues without being asked. An automation pairs a trigger with what to run:

• A scheduled automation runs a saved script — a named, reusable bash script that runs in the project sandbox with the same CLIs and tooling the agent uses — on a cron schedule.
• A signal automation runs when a signal fires — an event Sazabi detects in your project, such as a new or spiking error pattern in your logs. The Sazabi-managed Investigate new error patterns is one example: it opens issues for new error patterns as they appear.

Together these let Sazabi monitor your systems and open issues on its own, rather than waiting for you to ask. See Create automations and Manage scripts.

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