Incidents and maintenance

Both features are enabled by default and both are a single switch. Turning one off removes its API routes, its effect on the snapshot and, for incidents, the RSS and Atom feeds.

incidents: { enabled: true },maintenance: { enabled: true },

The incident model

interface Incident {  id: string;  title: string;  status: "investigating" | "identified" | "monitoring" | "resolved";  severity: "minor" | "major" | "critical";  affectedMonitors: string[];  auto: boolean;  updates: IncidentUpdate[];  createdAt: Date;  updatedAt: Date;  resolvedAt: Date | null;}

Creating one

heyo-status incident create \  --title "Elevated API latency" \  --severity major \  --monitors "API,Dashboard" \  --message "We are investigating elevated response times."heyo-status incident update inc_... --status monitoring --message "A fix is deployed."heyo-status incident resolve inc_... --message "Latency is back to normal."heyo-status incident list --status investigating

How incidents change the page

overall is computed in this order:

1. A maintenance window that is in-progress → maintenance.
2. Any active critical incident → major-outage.
3. Any other active incident → degraded.
4. Otherwise monitors decide: all failing → major-outage, some failing → degraded, none → operational.

Active incidents are published in the snapshot and rendered with their full timeline, each anchored at #incident-<id> so the RSS and Atom entries link straight to it.

The maintenance model

interface Maintenance {  id: string;  title: string;  description: string;  affectedMonitors: string[];  scheduledStart: Date;  scheduledEnd: Date;  status: "scheduled" | "in-progress" | "completed";  createdAt: Date;}

Status is derived from the clock, not set by hand: reading upcoming windows refreshes scheduled → in-progress → completed against now before returning them. scheduledEnd must be after scheduledStart.

Creating one

heyo-status maintenance create \  --title "Database upgrade" \  --description "Read-only for about 30 minutes." \  --monitors "API,Dashboard" \  --start 2026-02-01T02:00:00Z \  --end 2026-02-01T03:00:00Zheyo-status maintenance list

Alert suppression

While a window is in-progress, the monitors it names are excluded from:

• monitor.down, monitor.recovered and ssl.expiring events, and
• automatic incident creation and reconciliation.

They are still checked and their results are still stored, so the uptime grid stays honest about what actually happened. A window with an empty affectedMonitors suppresses alerts for every monitor.

Feeds

With incidents.enabled, the catch-all route publishes the newest 50 incidents as both RSS 2.0 and Atom:

GET /api/heyo-status/rss.xmlGET /api/heyo-status/atom.xml

Entries are titled <title> (<status>), link to the #incident-<id> anchor on siteUrl (falling back to the request origin), and carry the incident's timeline as the description. See Badges, feeds and metrics.