Make incident status canonical and derive component status from impacts

[jbrooksuk]

Different parts of Cachet answered the same questions differently. This makes them agree, before incident-response features get built on top of a model that contradicts itself.

Is this incident open?

Three definitions could disagree: the status column, an accessor reading the newest update, and a banner query treating an incident as resolved if either said so. An incident could read as resolved on the banner while its own page said otherwise.

The column is now canonical. A SyncIncidentStatus action keeps it in step on create, edit and delete of updates, latestStatus becomes an alias for it, and the latest-update join disappears from Status. Update-driven status changes now apply to every status, not only fixed.

Who may see this incident?

Publication and visibility were decided independently at each read surface, and several forgot one of the two. A single viewableBy scope now decides both, and every surface goes through it — the API, MCP, RSS, the status page, the timeline, the system status and the component overlay.

That closes: embargoed incidents appearing in the RSS feed, hidden incidents being readable by guid and flipping the public banner, an unpublished incident's updates being listable by id, and the component overlay ignoring publication entirely.

What colour is this component?

The badge and the banner were computed by different rules — the badge accounted for incidents, the banner only read the raw column — so every component could show red under "All systems operational".

Component status now splits into a baseline (the column, what operators and monitoring assert) and an effective status (what the page shows). Incidents and maintenance contribute impacts on top of the baseline without ever writing to it, and the most severe wins rather than the most recent, so a minor incident can no longer mask a major one. A maintenance window in progress replaces the baseline, so expected downtime is not reported as an outage, while an incident raised during the window still surfaces. The banner is computed from the same effective statuses, and a single component under maintenance no longer masks a fleet-wide outage.

Resolution therefore restores nothing, because nothing was overwritten: the impact simply stops counting. The rewrite of every pivot to operational on resolution is gone — it destroyed the record of what an incident imposed, and only ran on one of the paths that resolve an incident.

Why did this component change?

The component_status_changed webhook only fired for API and MCP edits, because the event lived inside UpdateComponent and four of the six writers never called it — the dashboard toggle and edit form, the monitor, and the OhDear import all wrote the column directly.

All six now route through a ChangeComponentStatus command, so the event fires wherever a status changes, and every change records what asserted it (manual, monitoring, import, system), who caused it, and an optional reason.

Also

• Maintenance windows say what each component should look like while they run, and the most severe status wins across overlapping windows. The pivot column has been written since 2016 and read by nothing; the dashboard hardcoded it to operational, so the form now offers a status defaulting to under maintenance. No scheduled job is involved — the window is derived from the clock.
• Both component pivots gain a unique constraint on their parent and component, with a migration that collapses pre-existing duplicates to their most severe impact.
• Resolving the current user is now the caller's job: models and actions take a user rather than calling auth(), supplied by the controllers, MCP tools, Filament actions and views entitled to know it. Writes that belong together — a status and the record explaining it, an update and the incident status it drives — are wrapped in transactions, with events dispatched after commit.
• A null scheduled_at no longer fatals the schedule status accessor, and metric charts order by order rather than by their decimal places.

Compatibility

• component.status in the API keeps its meaning as the baseline and its wire format. A sibling latest_status is added for the effective status.
• component_status_changed webhook payloads gain a source field, and old_status may now be null where a component had no prior status.
• Incidents created through the API or MCP without an explicit visible remain authenticated-only, as they always have. Because impacts are now gated on visibility, such an incident no longer changes the public status page. Pass visible: true for an incident that should be publicly visible.
• Resolved incidents keep their recorded impact, so GET /incidents?include=components now shows the status the incident imposed rather than operational.

Verification

933 tests passing, Pint and PHPStan clean, migrations verified from a fresh build including the deduplication path against duplicate rows.

New coverage includes severity precedence over recency, the maintenance mask with a failing monitor, per-window maintenance statuses and overlapping windows, exclusion of embargoed, hidden and resolved impacts, parity between eager-loaded and lazy resolution, the read policy per surface, and the status-change log with its source and causer.

Still open

Recording or clearing an impact emits no event — only baseline changes do — so a consumer watching webhooks sees "someone set this component" but not "an incident took it down". Related: because effective status now depends on the clock, a component's public status can change with no write at all when a window opens or an embargo lifts, and nothing fires then either. Both are worth settling before anything starts consuming these events.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188UuLsNZ39q6Yw8BUBVH3b