Components and status pages
Incido separates two ideas that are easy to merge in conversation but serve different roles in the product. Organization components are the shared catalog of services or product surfaces that can be affected by incidents and maintenances, linked from monitors, and used when calculating health. Status page structure is how a specific status page arranges those services for a given audience: order, optional grouping, and optional display names or descriptions that differ from the catalog defaults.
Thinking in two layers keeps your source of truth consistent while letting each status page stay readable. You define impact and automation against organization components once; you tune presentation per page where customer-facing and internal views diverge.
Organization components
Organization components are created under Settings and described in depth in Components and taxonomies. When you attach a component to an incident or maintenance, you are deciding which parts of your product are impacted. Monitors map to the same catalog so automated incidents affect the right surfaces. Names and descriptions should reflect what customers recognize—API, checkout, mobile app—rather than internal hostnames alone, because those labels flow into public communication unless you override them on the status page.
Deletion and health rules apply at this layer: a component cannot be removed while a status page or monitor still references it, and public operational versus degraded signals are derived from active incidents and maintenances against these catalog entries.
Status page layout
Each status page has its own tree of entries. A leaf row is tied to an organization component. Its health on that page comes from that underlying component, but you may override the public name or description for that page only—useful when the same catalog entry should read “Core API” externally and stay “api-gateway” internally in the Dashboard, or when two audiences need different wording without duplicating catalog rows. Those overrides are also what visitors see in the affected services tags on public incident and maintenance detail pages for that status page, which keeps detail-page communication aligned with the main status view.
A group row exists only on the status page: it has no linked organization component and acts as a container for children. Groups let you collapse related services under headings such as “Platform” or “Regional services” so visitors scan faster. Grouping is subject to your plan’s feature flags; see Status pages for how to add and order components.
Publication of incidents and maintenances to a page requires overlap between affected organization components and components placed on that page’s tree. If an incident affects only catalog components that never appear on a given status page, that page will not show the incident even if everything else matches filters—by design, so each audience only sees relevant impact.
Concrete Examples
One deployment, two customer-facing names. Your organization catalog holds a single component, Core application, because one backend stack serves both the operator dashboard and the customer-facing REST API. Monitors, correlation groups, and incident impact all attach to that one catalog entry so automation stays honest about blast radius. On the public status page you still want customers to see Dashboard and API as separate rows. Add two leaf rows, both linked to Core application, and override each leaf’s display name on the page so the labels match how you market the product. Health stays aligned: an incident that marks Core application degraded updates both rows, because they read the same underlying component. Incido allows more than one status-page leaf to point at the same catalog row on purpose—use that when audiences slice one system into different names without cloning catalog entries.
Several backends, one product story. Your catalog might list Product UI, Payment processing, and Email delivery because those are the pieces your team operates and attaches to incidents. Customers only experience your workspace as a single surface. On the customer status page, create a group whose public name is that surface—Acme workspace—and place three child leaves underneath, each tied to one of those catalog components. Then turn off Show child components on the status page for that group (a group-only option in the status page Components tree). Visitors see a single row for Acme workspace; its status and availability still roll up from the hidden children, so a payments outage degrades the group even though the child names never appear. Your internal status page can omit that pattern and list Product UI, Payment processing, and Email delivery as plain leaves so operators see exactly which subsystem is red.
Together, these patterns show how the catalog stays aligned with how you run the platform, while per-page layout decides whether you split one system for clarity or collapse several systems behind one public label.
Troubleshooting
Customers see a label you did not expect. Check for a status page override on the leaf row; if none exists, the organization component’s translated name is shown.
An incident does not appear on one status page. Verify the page’s publication filters and that at least one affected organization component is present on that page’s component tree (see Status pages).
You cannot add children under a row. Only group rows (entries without a linked organization component) accept children. Linked leaves cannot be turned into folders; create a group and move leaves beneath it.