Skip to main content
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.
Limited releaseThe component status page (labeled Components in the dashboard sidebar) is currently in limited release and is not yet visible in every organization. The sazabi components CLI commands follow the same release: they appear once the page is enabled for your organization. Components and their statuses are still available through the API. Contact support to request access to the page.

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

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

​
Team ownership

A component may have one owning team, assigned from the project Status page (see Manage members for how teams are grouped). Ownership is more than organizational: a notification or task-creation rule can target the owning team instead of listing components by hand, and moving a component to another team re-routes its next issue with no rule edit. See Route notifications for how a rule targets a team.

​
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). The CLI commands are available once the page is enabled for your organization (see the note above); until then sazabi components is not listed. Read the current status summary and list, and register a component:
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 lifecycle, 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

Issues

Link issues to components to drive status.

Route notifications

Route component- or team-scoped issues with delivery rules.