Components, Severities, And Status Catalogs
Before you can communicate incidents and maintenances effectively, you need to define the vocabulary your team and your customers will use. Components describe the parts of your service. Severity levels classify how bad an incident is. Status catalogs define the workflow steps incidents and maintenances move through. Together, these settings shape every piece of public communication Incido produces.
Components
Organization components and status page layout
Incido uses two layers. Organization components (the entries you manage here under Settings) are the canonical list of services or product surfaces that incidents, maintenances, and monitors attach to. They are shared across your whole workspace. Status page layout is separate: each status page has its own tree of rows—some linked to an organization component (health follows that component), some groups that only exist on that page to hold related rows together. You can reorder entries, override how a linked component is labeled on one page, and show different trees on different pages without duplicating the underlying catalog.
That split means you decide what can be impacted when you model organization components, and you decide how each audience sees that model when you edit a status page’s component tree. For naming guidance in practice and a worked example, see Components and status pages and Status pages.
Naming and using organization components
Components represent the individual services, systems, or infrastructure pieces that make up your product from your customer's perspective. When you create an incident or maintenance, you select which components are affected, and that selection drives what customers see on the status page and how aggregate service health is calculated—after those components appear on the relevant status page trees.
Think about components from your customer's point of view, not only your internal architecture. "API", "Web Dashboard", "Email Delivery", and "Mobile App" are more useful to customers than "us-east-1 k8s cluster" or "Redis cache layer" when those internal pieces are not how customers think about your product. Customers want to know which part of the product they use is affected, not which server name failed.
On a status page, groups are structural rows without a linked organization component. They create collapsible sections so visitors can scan related services together. Groups are configured per status page (not on this Settings screen) and are plan-gated — check your plan if you do not see the grouping option on the status page editor.
Deleting a component is protected by guard rules. If a component is still linked to a status page or referenced by a monitor, deletion is blocked and the error message tells you which status pages or monitors are affected. Remove those references first, then delete the component. This prevents orphaned references that would break your status page layout or monitor configuration.
Component health on each catalog row reflects incidents (and monitors where your setup ties them in)—not maintenance expected impact by itself. Maintenance can still list a component as affected and record maintenance impact intervals for timelines and strips; that is separate from the live health enum. Incident periods that make the component non-operational are written to outage history for metrics when the rules say so; maintenance-only windows do not create incident outage rows. When qualifying incidents end, the component returns toward Operational per incident rules. You do not need to manually reset catalog health after maintenance alone.
When you open a component in the Dashboard, the page includes Recent activity and Ongoing impact. Recent activity merges maintenance impact intervals (from the moment an affected component row is in progress until it is completed or skipped) with incident outage history from automatic tracking when incidents drive non-operational status, sorted with the newest events first. The window is evaluated in UTC and focuses on episodes that are still open or ended within roughly the last two weeks, while Ongoing impact lists current open maintenance intervals and open incident outages side by side so you can see everything still affecting the component without hunting through older history.
Severity levels
Severity levels classify incident impact and set customer expectations about urgency. Your organization starts with four defaults — Critical, Major, Minor, and Trivial — each with a color, icon, and priority order. Severity labels appear prominently on the public status page, so they are a direct communication tool, not just an internal classification.
You can customize severity levels to match your organization's language and incident response model. Rename them, change their colors and icons, reorder their priority, or add new ones. Each severity level has a unique key within your organization, a translatable name and description, and an enabled/disabled flag.
Default severity levels (the ones created during organization registration) cannot be updated or deleted. They serve as the baseline. Custom severity levels you create can be modified freely.
The number of severity levels your organization can have is governed by your billing plan, and the ability to create custom severity levels requires the Custom Severity Levels feature. If you are on a plan that does not include this feature, you work with the four defaults.
Incident status catalogs
Incident statuses define the workflow steps an incident can move through. Incido uses a two-level model: stages are fixed system-level gates (Triage, Active, Post Incident, Closed), and statuses are organization-configurable labels within those stages.
Each incident status has two communication layers. The internal layer is the status name, description, color, and icon your operators use in the Dashboard. The public layer is a separate public label, public color, and public icon that visitors see on status-page badges and timeline milestones. This split matters when your team wants one workflow vocabulary internally but a different phrasing externally. For example, you might keep a concise internal status called Active but show Identified publicly.
Your organization starts with built-in defaults that already include public presentation. You can add new statuses within any stage and define which transitions are allowed between them. The seeded defaults stay locked so every organization starts from a coherent baseline, while custom statuses let you adapt the public wording to your own process.
Status transitions control valid progression paths. Defining transitions prevents operators from making invalid state changes during high-pressure incidents — for example, you might want to ensure that an incident in Triage can only move to Active or Closed, not skip directly to Post Incident. Each transition can be marked as the primary outgoing transition for a status, which determines the default action offered in the Dashboard.
The incident workflow configuration defines two critical defaults: the default initial status (assigned to new incidents) and the incident suppression status (assigned to incidents that are automatically suppressed during active maintenance). Both must belong to the Triage or Active stage. The suppression status must have at least one outgoing transition to a Triage or Active status so that suppressed incidents can be un-suppressed when the maintenance ends.
Disabling a status removes it from the workflow for new incidents, but existing incidents that reference it retain their current status. You must manually transition those incidents before the disabled status fully drops out of use.
Custom incident statuses require the Custom Statuses feature on your plan. Without it, you work with the system defaults.
Maintenance status catalogs
Maintenance statuses follow the same two-level model as incidents, with five fixed stages: Draft, Scheduled, In Progress, Post Maintenance, and Closed. They use the same split between internal workflow labels and public presentation. That means a maintenance status can keep an internal name such as Reviewing while showing Completed publicly if that is the clearer message for customers.
The same concepts apply: you define custom statuses within stages, configure allowed transitions, and set a default initial status through the maintenance workflow. Transitions control valid progression paths and offer primary outgoing transitions for the Dashboard UI. Public labels, colors, and icons on those statuses shape what customers see in maintenance cards and projected timeline milestones.
Custom maintenance statuses are also gated by the Custom Statuses feature.
What changes on the public frontend
Organization component names and descriptions set the default labels used wherever those components appear on status pages unless a page-specific override exists. Grouping and order are controlled on each status page; changing them updates only that page’s layout. Renaming a catalog component updates every place that still inherits its label.
Severity level names, colors, and icons appear on every published incident. Changing a severity level's label or color updates how it displays on both new and existing incidents.
Incident and maintenance statuses no longer expose their raw internal names automatically on the public frontend. Customers see each status's public label, public color, and public icon instead. Changing those public fields updates both current badges and historical timeline milestones, because public rendering always uses the latest status configuration with fallback to the organization's default language when a requested translation is missing.
Operational effects
These settings are the shared language layer for Incidents, Maintenances, and Status pages. Poor naming or inconsistent taxonomy increases response friction during active events because operators and customers interpret status labels differently. Reviewing component vocabulary, per-page layout in Status pages, and severity semantics regularly keeps public communication predictable. For layout decisions spanning multiple pages, see Components and status pages.
Troubleshooting
A component cannot be deleted. The component is still referenced by a status page or monitor. The error message lists the specific references. Remove the component from those status pages or monitors first, then retry deletion.
A severity level or status cannot be created. Check your billing plan limits. The number of severity levels, and whether custom statuses are available, depend on your plan's feature set.
An incident is stuck on a disabled status. Disabling a status does not automatically migrate existing incidents. Manually transition the affected incidents to an enabled status, then the disabled status drops out of the active workflow.
Component health does not match expectations after an incident closed. Component status is calculated from all active incidents and maintenances. If the component still shows as degraded, check whether another active incident or maintenance is affecting it.