Core Concepts
Understand Sazabi's AI-native approach to observability where conversations replace dashboards.
Sazabi is an AI-native observability platform. Unlike traditional monitoring tools that center around dashboards and charts, Sazabi treats conversations as the primary unit of work. You ask questions in natural language, and Chat investigates your production systems to find answers.
Threads
Every investigation in Sazabi is a thread. A thread is a conversation between you and Chat about your production systems.
- Threads are persistent. Your investigation history is saved, so you can return to a thread days later and pick up where you left off.
- Threads can be shared. Send a link to a colleague so they can see exactly what you investigated and what the assistant found.
- Threads can be forked. Branch off from any point in a conversation to explore a different hypothesis without losing the original context.
- Threads can be archived. Clean up your sidebar by archiving threads you no longer need, while keeping them searchable.
Think of threads like Slack conversations or email threads, but for debugging production issues.
Chat
The assistant is your investigative partner. It has access to your logs, metrics, and traces, and can take actions on your behalf.
What the assistant can do
- Query your data. The assistant writes and executes queries against your logs, metrics, and traces to answer your questions.
- Run code in a sandbox. When analysis requires computation (parsing, aggregation, visualization), the assistant runs code in a secure sandbox.
- Create alerts. When the assistant detects an issue worth tracking, it can create an alert that notifies your team.
- Update status pages. The assistant can update status components to reflect ongoing incidents.
- Connect to external tools. Through MCP connectors, the assistant can interact with Linear, Slack, Datadog, and other tools your team uses.
How the assistant reasons
The assistant explains its thinking as it works. You see which tools it calls, what queries it runs, and how it interprets the results. This transparency lets you verify its reasoning and guide the investigation when needed.
Organizations and Projects
Sazabi uses a multi-tenancy model to keep your data organized and secure.
Organizations
An organization represents your team or company. Organizations are the boundary for:
- Team membership and permissions
- Billing and subscription
- Integrations (Slack, incident.io, etc.)
Projects
Projects live within organizations and isolate your telemetry data. Common patterns include:
- Separate projects for production and staging environments
- Separate projects for different applications or services
- Separate projects for different teams within a larger organization
API Keys
API keys are project-scoped. When you send logs to Sazabi, the API key determines which project receives the data. This ensures production logs never accidentally mix with staging logs.
Data Sources and Backends
Sazabi separates where your logs come from and where they live.
Data Sources
A data source is a system that sends logs to Sazabi. When you configure a data source, you are telling Sazabi to receive and store logs from that system.
Examples of data sources:
- OpenTelemetry collectors forwarding logs
- AWS CloudWatch subscriptions
- Vercel log drains
- Direct API ingestion from your application
Backends
A backend is a system that Sazabi queries to retrieve logs. Sazabi supports two types of backends:
- Sazabi backend: The default. Logs you send to Sazabi are stored in our managed ClickHouse infrastructure and queried directly.
- External backends: Connect your existing Datadog, AWS CloudWatch, or other logging systems. Sazabi queries them in place without moving your data.
With external backends, you can use Chat to investigate logs that live in systems you already use, without changing your logging pipeline.
Alerts
Sazabi takes a different approach to alerting. Instead of configuring static thresholds, Chat detects issues during investigations and creates alerts when it finds problems worth tracking.
Alert Lifecycle
Alerts have a simple lifecycle:
- Open: The assistant detected an issue that needs attention.
- Resolved: The issue has been addressed or is no longer occurring.
Delivery Channels
When an alert is created or changes state, Sazabi can notify your team through:
- Slack: Post to a channel with inline actions to mute, unmute, or resolve.
- Email: Send notifications to team members.
- Webhooks: Trigger custom workflows in your own systems.
- incident.io: Create incidents automatically in your incident management platform.
MCP Connectors
MCP (Model Context Protocol) connectors extend what Chat can do by connecting it to external services.
How connectors work
When you install an MCP connector, the tools from that service become available to the assistant. For example:
- Linear connector: The assistant can create issues, search for existing tickets, and update issue status.
- Slack connector: The assistant can search messages, post updates, and gather context from team conversations.
- Datadog connector: The assistant can query dashboards, metrics, and logs from your Datadog account.
Available connectors
Sazabi supports both hosted MCP servers (Linear, Slack, Datadog, incident.io) and custom MCP servers. If you run your own MCP server, you can connect it to give the assistant access to your internal tools and data.
Connectors are configured at the organization level and available to all projects within that organization.