Status pages
A status page is the public website your customers visit to check whether your services are up, read incident updates, and see scheduled maintenance. You can run multiple status pages from a single organization — for example one per product or audience.
Creating a status page
Create a status page from Operations > Status Pages by providing a clear name and key, then selecting the theme that should control public appearance. If no custom theme is available, Incido uses your organization default theme automatically. After saving, enable the page so customers can access it through its configured domain or subdomain.
Adding components and structure
Components represent the services displayed on your status page. They let customers see at a glance which parts of your platform are healthy.
Go to the status page detail view and open the Components tab. Click Add Component to add either a group (a container that organizes children) or a linked component (a leaf that displays an organization-level component from Components and taxonomies). The form shows a type choice at the top: when you select Group component, you provide a name, description, and options for whether child components are shown on the public page. For groups, expanded by default is always available: when children are shown, it controls whether nested child rows start open on the public page, and when you also display percentage and daily history, the same setting covers whether the daily history strip starts open together with those children. When children are hidden, customers no longer see those child rows, but the group can still show rolled-up health for the subtree; if you show percentage and daily history, expanded by default applies only to the daily history strip, and the rolling percentage in the row header stays visible when the strip is collapsed, just like on a linked component. If child rows are hidden and you do not show the daily strip, that toggle has no effect on what customers see until you enable the strip. On the default public theme, expanded by default means that content is shown immediately and the row does not offer a collapse control, because the configuration is meant to keep that part of the tree visible for everyone. When expanded by default is off for a row that can show nested children or the daily strip, visitors can still open or close that detail during their session using the row’s expand control; a full page load returns to the default you set here. When you add a linked component, you choose the organization component to display and may optionally override its name or description. Expanded by default for a linked row appears only when percentage and daily history is selected, because it only affects the daily strip. Groups require the Component Groups feature on your plan; if that feature is not available, only linked components can be added.
Critical for parent rollup appears for every node (group or leaf). It answers how a failure on that branch should read for parent groups on the public page, not whether the underlying component is actually down. When it is enabled, a full outage on that child can surface as a full outage on the parent whenever the rollup rules say the situation is severe enough—for example when another critical sibling is also fully down, or when every direct child rail is fully down. When it is disabled, a full outage on that child usually caps the parent at partial outage if at least one sibling rail is still healthy, which matches how teams describe “cards still work but Twint does not” under a shared Acquiring heading. The leaf row itself still shows the real severity from incidents and monitors; this flag only changes how ancestors summarize multiple children. Configuration import and export carry the same setting under is_critical for each component record, defaulting to critical when an older archive omits the field.
Historical availability on public page is a separate choice for each row. It controls whether customers see the rolling availability percentage for the current history window, the per-day history strip, both, or neither. It does not remove the row or hide current operational status (for example Operational versus Degraded); that stays visible so the page still answers whether something is up right now. New components default to showing both the percentage and the daily history, matching what existing pages had before this option existed. Configuration archives include the value as availability_display on each component; when an older archive omits it, Incido assumes the full display.
Drag rows to reorder. The public page reflects the order you set here. Unless you hide historical availability for a row, customers still see the usual rolling percentage text for the configured window (today the last 90 days) along with current status.
Content publishing — how incidents and maintenances appear
You don't have to manually assign incidents to status pages. Incido publishes them automatically when all conditions are met:
| Condition | Incidents | Maintenances |
|---|---|---|
| Severity level matches the page's configured levels | Yes | — |
| Current status matches the page's configured statuses | Yes | Yes |
| At least one affected component exists on the page | Yes | Yes |
| Tags pass the page's required/excluded tag filters | Yes | — |
When an incident or maintenance is newly published to a status page, subscribers of that page are notified automatically.
Manual control
If needed, you can unpublish an incident or maintenance from a status page and later republish it. This takes effect immediately on the public status page and is recorded in the audit trail, so your team can explain why a visible event was temporarily removed or restored.
Configuring filters
You can fine-tune which content appears on each status page through applicable severity levels, incident statuses, maintenance statuses, and incident tag filters. This lets you run a customer-facing page that shows only relevant issues while keeping broader operational visibility elsewhere.
Email sender settings
Each status page can use its own email sender address and name for subscriber notifications. When not configured, the organization defaults are used. The sender address must be verified before it can be selected. See Email sender addresses.
Custom domains
Custom domains let you publish a status page on a host name you own, such as status.example.com or an apex domain when your DNS provider supports it. You manage this from the status page view by opening Edit in the Custom Domain section, which now opens a modal wizard. In the first step you enter or update the hostname, and Incido immediately starts the setup with Cloudflare as soon as you continue. This first transition is where the pending domain request is created and where the initial DNS instructions are generated.
The second step shows the DNS records you must add at your DNS provider, with explicit Type, Domain, and Value columns so your team can copy values without guessing the expected format. The wizard then attempts a validation refresh when you confirm this step. If verification is already complete, the final step reports that the domain is active. If verification is still pending, the final step explains that DNS propagation can take time and that Incido will keep retrying automatically in the background. The summary now includes a prominent validation state panel with a status icon so operators can immediately tell whether the domain is already active or still pending. When operators click through this validation step repeatedly within the one-minute retry cooldown window, the wizard still continues to the summary view instead of blocking the flow with a cooldown error.
Outside the wizard, the status page view shows the currently active host and, when present, a separate pending-validation host. Each host opens its own details modal. The pending modal includes current verification state, DNS records, and a manual refresh action for immediate re-checks. The active modal keeps DNS records visible so operators can verify routing even after activation. If you replace an existing custom domain, customers keep reaching the old host until the new host is verified, then the previous host is removed asynchronously through retryable background jobs. If you explicitly remove the currently active custom domain without a replacement, Incido immediately falls back to the status-page subdomain route and invalidates public cache right away while provider-side deprovision continues in the background.
Pending domains that never verify are removed automatically after seven days. This timeout protects you from recurring provider charges for domains that were requested but never completed. If a domain is still pending close to expiry, re-check the CNAME and TXT records in the pending-domain modal and trigger Refresh status after propagation. The same instruction set remains visible after activation, so operators can still verify DNS values later without creating a new request.
What changes on the public frontend
What you save on this status page is what customers get on the public site. Enabling or disabling the page controls whether the address is reachable; the component tree controls how services are grouped and described; and each row’s historical availability choice controls whether visitors see a rolling percentage, a per-day history strip, both, or neither. Current status for a row stays visible unless grouping rules hide that row. Publication filters, the assigned theme, and domain setup work the same way—they change timelines, visuals, and where people land without any manual publishing step beyond saving configuration here.
When historical availability is visible, the percentage and the daily strip read from the same history for that row. Time counted as partial or full outage lowers the rolling percentage and marks days on the strip; degraded periods change badges and how days are colored, but they do not pull the percentage down. Group rows roll that picture up across everything underneath them. When a visitor opens the default theme’s day tooltip on the strip, the title line shows the calendar date together with UTC, matching how the strip’s times are interpreted. Each affected incident or maintenance appears as a single row with a small colored dot: incidents use the same severity colors as the strip for that outage, and maintenances use the maintenance color, so customers can tell planned work from incident impact without separate “Incidents” and “Maintenance” headings. If a tooltip includes an outage duration for a finished window, the default theme spells it out as days, hours, and minutes (for example one hour and one minute) instead of a single decimal hour. For an ongoing outage, the same line starts with the ongoing placeholder in the cached page; once the visitor’s browser runs the default theme script, that value is replaced with elapsed time in the same day-hour-minute style, updated periodically without requiring a fresh cache of the whole page. When you show both the percentage and the strip, the percentage stays in the header and the strip sits in the row’s expandable region—beside listed child rows when a group shows children, and on its own for linked components or groups that hide child rows. Expanded by default decides whether that region starts open; visitors can still toggle it during a visit, and a full page load returns to the default you configured.
Availability is calculated over 90 days. The percentage always reflects that full window. On phones and narrow browsers the default theme shows fewer daily columns so the chart stays readable, rather than squeezing every day into a thin bar. Names indent to show depth without stealing width from the chart; grouped services open into a simple list with light dividers instead of stacked mini-cards, and wider layouts keep status and percentage lined up in a column while small screens stack content for clarity.
Publication rules still decide which incidents and maintenances appear on lists and detail pages. Changing the theme updates the public look immediately, and unpublishing removes content from public view immediately. When a verified custom domain is active, Incido treats it as the canonical address and sends subdomain visitors there; when no custom domain is active, the status-page subdomain keeps serving the page, including while a new custom domain is still verifying. Hostnames you removed in the past resolve to your current public host instead of showing a dead page.
The status hero at the top of the default status page summarizes the page in one glance. Severity still comes from the same root-level rollup as the component tree: each root row contributes its rolled-up status and Critical for parent rollup, merged with the same rules used inside groups, so monitor- or incident-driven impact surfaces when it flows into those rows—including when a leaf is non-critical and a sibling stays healthy, so the headline can read partial outage instead of full outage. If there are no components on the page, the hero stays in the all operational posture. When that rollup is operational but a published maintenance is in progress on the page and affects at least one component represented in the tree, the hero can switch to a dedicated maintenance ongoing presentation without forcing rows to fake degraded severity when the underlying component status is still healthy. A published incident that does not touch any organization component on the page does not change headline severity by itself; customers may still see that incident elsewhere on the page. Incident triage and organization components in under investigation can lag or read as healthy in this rollup until component status reflects impact, which matches how row badges are computed.
When the headline is maintenance ongoing or incident-driven (degraded, partial, or full outage), the default theme can add a short line naming affected leaf services under the title, using the same sentence pattern in each case: a single name, two names joined with and, three names, or three names plus a count of additional matching leaves when the list is longer. That line is separate from the optional combined incident and maintenance link strip described next.
When the headline state is not the ordinary all operational posture, the default theme can add a short combined list under the title: up to three entries mixing ongoing published incidents (triage or active, the same scope the product uses elsewhere for “ongoing”) and published maintenances that are in progress, sorted so higher-impact items tend to appear first and ties favor the most recently updated work. Each entry is a rounded card-style link with the same layout: a short label (Active incident or Ongoing maintenance), an em dash, a bold title, and a trailing arrow, linking through to the public detail page. Separate overflow lines can point to the full incidents list and the full maintenances list when more items exist than fit in the three slots. If severity is elevated but nothing qualifies for that combined list—for example monitor-only impact with no matching ongoing incidents—customers still see the severity-driven headline but may see no links in that header strip and should rely on the component section and any recent-incidents section you keep enabled. For maintenance-only headline states, the same list can surface ongoing maintenances without requiring an incident.
In the Services block, a row whose underlying health readout is operational can still pick up maintenance coloring when a published maintenance is in progress overall and that component’s entry on the maintenance’s affected list is also set to in progress for that work, so components that are only scheduled or already completed for that same maintenance do not pick up the maintenance badge prematurely or after their slice of the work is done.
Operational effects
Status page configuration is the control point that ties together incidents, maintenances, themes, and subscriber communication. Changes here affect downstream behavior in Incidents, Maintenances, Subscribers, and Themes and editors. Resource limits and feature availability can affect which options appear in this area, so teams should align their workflow with what is enabled in their workspace.
Troubleshooting
An incident or maintenance does not appear on the page. Confirm that publication conditions are met: matching status rules, relevant component overlap, and applicable severity or tags where required.
Customers can access the wrong page or cannot access the expected page. Verify the page is enabled and that domain or subdomain configuration matches the destination you intend to publish.
A custom domain stays pending and never switches. Open the pending domain details modal from the status page view and confirm that the CNAME and TXT records exactly match what your DNS provider currently has configured. After propagation, use Refresh status to run another verification cycle. If a pending domain reaches seven days without verification, it is removed automatically and must be requested again.
Components look out of order or grouped unexpectedly. Review ordering and grouping in the status page component tab, then refresh the public status page after saving.