Incidents
Updated 2026-09-08 · Pharos 0.5.10
Status and impact
Incident status is Investigating, Identified, Watching or Resolved — the same integers Cachet used. Component status is separate:
| Value | Label | Counts as down |
|---|---|---|
| 1 | Operational | no |
| 2 | Degraded performance | no |
| 3 | Partial outage | yes |
| 4 | Major outage | yes |
| 5 | Under maintenance | no |
Impact — minor, major or critical — is stored separately from status and is meant for reporting and for whatever consumes the outgoing webhook.
Visibility
Only public incidents reach the status page and the public API. Anything marked internal is stored and visible in the admin only. There is no signed-in customer view yet, so authenticated currently behaves the same as internal.
Backdating
Set Occurred at to any past timestamp; the public page groups incidents by that date. How far back the page lists days is the Days of incident history setting, 1 to 30.
Templates with variables
Templates are applied through the API, not the admin form. Placeholders look like
{{server}}, are case-insensitive, and tolerate inner spaces. An unknown
placeholder is left in the text verbatim rather than blanked — publishing
“Outage on .” to customers would be worse than publishing the placeholder.
There is no admin screen for creating templates yet. Create them with
php artisan tinker or directly in the incident_templates table.
What happens when you resolve
Resolving puts every attached component back to operational — from the admin, from the API, and when a check closes an incident it opened. To close an incident while leaving a component degraded, name that component explicitly in the same request.