Status Pages

Incidents & Updates

Incidents are the primary way to communicate service disruptions to your users. This page covers the full lifecycle: creating incidents, posting updates, resolving, and understanding the notification pipeline.

Creating incidents

You can create an incident from the dashboard or via the API. Both methods accept the same fields:

Field	Required	Default	Description
`title`	Yes	--	Short summary of the incident.
`impact`	No	`none`	One of: none, minor, major, critical.
`state`	No	`investigating`	One of: investigating, identified, monitoring, resolved.
`message`	No	--	Initial update message. If provided, creates the first timeline entry.

Dashboard: Navigate to your status page, click New Incident, fill in the form, and submit.

API:

curl -X POST https://usebeacon.pro/api/v1/pages/acme-cloud/incidents \
  -H "Authorization: Bearer bkn_live_a1b2c3d4e5f6..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "title": "Database connection timeouts",
    "impact": "major",
    "state": "investigating",
    "message": "We are receiving reports of intermittent database connection failures affecting the API and dashboard."
  }'

Response:

{
  "id": "9f1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "title": "Database connection timeouts",
  "impact": "major",
  "state": "investigating",
  "resolved": false,
  "resolved_at": null,
  "created_at": "2026-04-04T14:32:00Z",
  "updated_at": "2026-04-04T14:32:00Z"
}

Impact levels explained

Choosing the right impact level helps users understand the severity of an issue at a glance.

Level	Use when	Example
`none`	Informational only, no user impact.	Planned infrastructure migration notice.
`minor`	Small subset of users or non-critical feature affected.	Slow search results for users in one region.
`major`	Core functionality impaired for many users.	API returning 500 errors on 30% of requests.
`critical`	Complete outage or data integrity risk.	All services unreachable due to network failure.

State transitions

An incident progresses through these states:

investigating  -->  identified  -->  monitoring  -->  resolved

Investigating — You know something is wrong but have not found the root cause. This is the default starting state.
Identified — The root cause is known and a fix is being worked on.
Monitoring — A fix has been applied and you are watching metrics to confirm stability.
Resolved — The issue is fixed. The incident moves to the history section of the public page.

You can skip states if the situation warrants it. For example, you can go directly from investigating to resolved for quick fixes. However, following the full progression gives subscribers more context.

Posting updates

Updates form the timeline of an incident. Each update is a timestamped message that appears on the public page and triggers subscriber notifications.

From the dashboard, open the incident and click Add Update. Via the API:

curl -X POST https://usebeacon.pro/api/v1/incidents/9f1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c/updates \
  -H "Authorization: Bearer bkn_live_a1b2c3d4e5f6..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "message": "Root cause identified: connection pool exhaustion on the primary database. Scaling up connections now."
  }'

Response:

{
  "id": "a2b3c4d5-e6f7-8a9b-0c1d-2e3f4a5b6c7d",
  "incident_id": "9f1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "message": "Root cause identified: connection pool exhaustion on the primary database. Scaling up connections now.",
  "created_at": "2026-04-04T14:47:00Z"
}

Resolving incidents

To resolve an incident, update its state to resolved and set resolved to true. This sets the resolved_at timestamp and moves the incident to history.

curl -X PATCH https://usebeacon.pro/api/v1/incidents/9f1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c \
  -H "Authorization: Bearer bkn_live_a1b2c3d4e5f6..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "state": "resolved",
    "resolved": true
  }'

Auto-created incidents

When a monitor detects a failure (HTTP check returning non-2xx, or a heartbeat missing its window), Beacon automatically creates an incident on the linked status page with:

A title derived from the monitor name (e.g. "API Monitor: Service Unreachable").
Impact set based on the monitor configuration.
State set to investigating.
An initial update message describing the failure.

When the monitor detects recovery, the incident is automatically resolved and the component status is restored to operational.

Notification pipeline

When an incident is created or updated, Beacon sends notifications through multiple channels:

Team emails — All workspace members with notification preferences enabled receive an email.
Subscriber emails — All confirmed subscribers on the status page receive a notification email.
Outgoing webhooks — If configured, a JSON payload is sent to your webhook endpoints.

Notifications are dispatched asynchronously via a background queue. Delivery is typically within a few seconds of the incident event.

Important: Subscriber notifications are only sent for incidents on public pages. Private page incidents only notify workspace team members.