Service status

The Status page shows the health of your services at a glance. Rather than computing status from thresholds, Sazabi derives it from the issues you already have: when a component-linked issue is open, that component is degraded or down; when the issue resolves, the component recovers. Open it at the project Status page.

Outcome: a status view that stays current from your issues, with no separate health rules to maintain. Time: a few minutes to review and tidy components.

Components

A component is a service or system element the status page tracks. Each component has a current status (below) and a lifecycle state of active, inactive, retired, or merged.

Components come from three origins:

• User declared — you registered the component explicitly.
• Code detected — discovered from your connected code.
• Log observed — discovered from the data you send.

Because components are discovered as Sazabi observes your systems, the list fills in on its own; you refine it rather than build it by hand.

Component statuses

Every component is in one of three statuses at any moment, derived from its linked issues rather than stored or set by hand:

When the linked issue resolves, the component returns to Operational on its own. See How issues drive status below.

Relationships

Components can relate to one another as part of (one component belongs to a larger one) or depends on (one component relies on another). Relationships describe your system's shape so status reads in context.

Component lifecycle

Each component moves through a small lifecycle: active components are tracked and shown by default, inactive components stay registered but are hidden from the status page by default, retired components no longer exist, and merged components have been folded into another. Keep the list accurate as your systems change:

• Rename a component when its name drifts from what you call it (renaming does not change its lifecycle).
• Retire a component that no longer exists — retiring can also close the issues linked to it — and restore a retired component if it comes back.
• Merge two components that turned out to be the same thing; the merged component's history follows into the canonical one.

Managing components from the CLI

You refine the component list from the project Status page in the dashboard, or with the Sazabi CLI (see CLI reference). Read the current status summary and list, register a component, and edit relationships:

sazabi status                      # Status page summary (components and their current status)
sazabi components list             # List all components
sazabi components register --name "API Gateway"
sazabi components relationships add --source <component-id> --target <component-id> --type part_of

Rename and merge are also CLI commands, and the dashboard's retire and restore actions map to deregister and reactivate (sazabi components rename|deregister|reactivate|merge). Because they change component topology, they run as a preview-then-commit flow: run the command to see the preview, then re-run it with the --request-id, --reason, and --confirm-preview-revision values from that preview to commit. See CLI reference for the full flag set.

How issues drive status

Status is derived from active issues:

• When a component-linked issue opens, the component moves from Operational to Degraded or Outage based on the issue's component severity.
• The status page reflects the change immediately.
• When the issue is resolved, the component returns to Operational.

Component-linked issues carry a component severity of degraded or outage — distinct from the four-level issue severity used elsewhere. See Issues for how issues link to components.

Timeline

Each component shows a timeline of its status over the past 7 days, plus a health summary — an uptime percentage, the number of issues in the window, and the longest outage. The timeline lets you see whether a component has been flapping or has had one sustained outage.

Further reading