Create manual incidents

Monitors open incidents on their own only through a service in auto mode. A manual incident with a Service pages exactly like one of those: see making it page someone.

When to create one manually

• A third-party dependency broke something user-visible: Stripe is degraded, AWS is throttling, your CDN is intermittently returning 502s.
• A bug surfaced in production that no monitor catches: UI broken for a specific browser, auth flow broken only for SSO users.
• Coordinating a multi-team outage in one canonical incident.
• Planned maintenance went sideways. A deploy you protected with a maintenance window broke something. The window held back the auto-created incident, so create one manually.

When not to

• Don’t manually create an incident for an outage that a monitor on an auto service will catch. Its auto-created incident will be cleaner.
• Don’t create an incident as a stand-in for a Slack message. If you don’t intend to publish it on a status page or trigger paging, message the team directly.

Two flavors of manual incident

Standalone incident (no status page)

Use this for internal tracking: you get the timeline without publishing, and paging once it has a service.

In the dashboard, go to Respond → Incidents and click Report incident. Give it a Title, a Severity and an Initial message, then click Report incident.

Through the API:

curl -X POST https://api.siteqwality.com/incident \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Stripe webhooks intermittently failing",
    "severity": "major",
    "message": "Seeing ~5% failure rate on inbound Stripe webhooks. Investigating."
  }'

Status-page incident (published)

Use this when the outage affects customers and they should know.

In the dashboard, go to Manage → Status Pages and open the page. On its Incidents tab, click Report incident, fill in the Title, Severity and Initial update, optionally pick the Affected monitors, and click Report incident.

Through the API:

curl -X POST https://api.siteqwality.com/status_page/<status-page-id>/incident \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Some webhook deliveries delayed",
    "severity": "minor",
    "message": "We are seeing increased latency on outbound webhooks. Investigating with our delivery provider."
  }'

The incident appears immediately on the public page, and the page’s confirmed subscribers are emailed.

Publish later, and keep notes internal

An incident you started without a page can go on one later. In the dashboard, open it and click Publish to status page: pick the page, check the public title and the first public update customers will read, choose whether to email the page’s subscribers, and click Publish update. Once it is on a page, the button reads Status pages, and its side panel lists each page with Unpublish. Through the API:

curl -X POST https://api.siteqwality.com/incident/$INCIDENT_ID/publish \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status_page_id": "<status-page-id>",
    "title": "Webhook deliveries delayed",
    "message": "Some webhooks are arriving late. We are working with our delivery provider."
  }'

DELETE /incident/$INCIDENT_ID/publish/<status-page-id> takes it off the page again.

The page shows the public title and public updates only. On an incident’s own page in the dashboard, updates are internal notes unless you switch the composer to Public update, so “failing over db-7” stays with your team. An update posted through the API is public unless you send "visibility": "internal". See public and internal updates.

Linking to affected monitors

If monitors exist for the broken thing, add them. The incident then shows as a banner on the matching status-page components and groups correctly in dashboards.

In the dashboard, open the incident and click Add monitor under Monitors. Pick the monitor and its impact (From severity, Degraded, Partial outage or Major outage), then click Add.

Through the API, send monitors on the create request. Each entry takes an optional impact (degraded, partial_outage or major_outage):

{
  "monitors": [
    { "monitor_id": "a3c1f5e0-1234-4abc-9def-aaaaaaaaaaaa", "monitor_type": "http", "impact": "major_outage" },
    { "monitor_id": "b7d2e601-5678-4def-9abc-bbbbbbbbbbbb", "monitor_type": "http" }
  ]
}

You can add, re-grade and remove monitors after creation too: see affected monitors and impact.

Making it page someone

A manual incident only pages when it has a service, and that service has an escalation policy attached. In the dashboard, pick the Service in the Report incident form. Through the API, send service_id at creation:

curl -X POST https://api.siteqwality.com/incident \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Stripe webhooks intermittently failing",
    "severity": "major",
    "message": "Seeing ~5% failure rate on inbound Stripe webhooks. Investigating.",
    "service_id": "<service-id>"
  }'

From there it behaves exactly like a monitor-opened incident: level 1 of the service’s policy fires immediately, the timeout is scheduled, and acknowledging (from the dashboard, the API, or a paged responder’s email or SMS link) cancels the escalation.

The service’s broadcast targets, if it has any, are also notified, even when the service has no escalation policy. An incident with no service pages nobody. If a manual incident did not page, check that it has a service and that the service has an escalation policy.

Move an incident to another service

Open the incident, click Edit, pick the right Service (or None) and click Save changes.

Through the API, send service_id on PUT /incident/{incident_id}. null detaches the incident from any service.

curl -X PUT https://api.siteqwality.com/incident/$INCIDENT_ID \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "service_id": "<new-service-id>" }'

Moving an open incident cancels the old service’s escalation and starts the new service’s escalation policy at level one, but only while the incident is still triggered: an acknowledged incident does not start paging again. The move is sent as a service-changed broadcast to the targets of both services.

An auto-created incident cannot move onto a service that already has an open auto-created incident. Merge the two instead: see merge incidents.

Severity guidance for manual incidents

Use case	Severity
Documentation site down	minor
Login broken for a subset of users	major
Full outage, billing affected, security event	critical

Severity drives display order, color and filters, and picks the paging urgency that each responder’s notification rules act on. See severity guidance.

Following up

After resolving, especially for major and critical incidents, open the incident’s Post-incident tab to start a postmortem (drafted from the timeline) and add action items. See write a postmortem and track follow-ups.

See also

Incidents overview Status vs responder_status, severities, lifecycle.

Status pages Where published incidents appear.