Overview
Status components represent logical services, APIs, or features tracked for health monitoring.
A component is a logical service, API, or feature that Sazabi tracks for health monitoring. Components appear on your project's status page and show whether each part of your system is operational, degraded, or experiencing an outage.
What is a component?
Components represent the distinct pieces of your system that your team cares about monitoring. Examples include:
- Services:
checkout-service,user-api,payment-gateway - APIs:
GraphQL API,REST API v2,Webhooks - Features:
Search,Notifications,Image Processing - Infrastructure:
Database,Cache Layer,Message Queue
Unlike traditional status pages where you manually define every component, Sazabi's components are discovered by Chat as it investigates production issues. When the assistant identifies a service as the source of a problem, it can register that service as a component.
Component data
Each component stores the following information:
| Field | Description |
|---|---|
| Name | A unique identifier within the project (e.g., checkout-service) |
| Description | Optional human-readable description of what the component does |
| First seen | Timestamp when the component was first discovered |
| Last seen | Timestamp when the component was last referenced in an investigation |
The name is the primary identifier and must be unique within a project. Two different projects can have components with the same name without conflict.
Component states
Components exist in one of two states:
Active
Active components appear on the status page and can have issues associated with them. Most components remain active once discovered.
Soft-deleted
Soft-deleted components no longer appear on the status page but their historical data is preserved. This is useful for:
- Services that have been decommissioned
- Components created by mistake
- Temporary services that are no longer relevant
You can restore a soft-deleted component if needed, bringing it back to the status page with its full history intact.
Uniqueness
Each component name must be unique within a project. If Chat encounters a service it has seen before, it references the existing component rather than creating a duplicate.
This uniqueness constraint means:
- Component names are case-sensitive (
checkout-serviceandCheckout-Serviceare different) - Renaming a component creates a new component rather than updating the existing one
- Historical issues remain associated with the original component name
When planning component names, use consistent naming conventions across your team. Chat learns from your patterns and will typically use similar naming for new discoveries.