Incidents

Stazus can open incidents from monitor signals. An editor can also create an incident manually. An incident keeps affected endpoints, recent checks, workflow status, comments, and checkpoints together.

Signal types

Incidents describe the kind of failure so responders can triage quickly:

• Availability — the request did not complete or the service was unavailable.
• Content — the response did not match its body expectation.
• Configuration — the service responded in a way that conflicts with the monitor configuration.
• Latency — response time crossed its learned or fixed threshold.
• Provider — a supporting provider signal contributed to the event.

Severity is warning or critical. Use critical for conditions that need an immediate response. Do not use it only because one check failed.

Investigate

Open the incident. Then work from the evidence closest to the failure.

1. Read the detection reason and identify the affected endpoints.
2. Compare the newest checks with the last healthy result.
3. Inspect status code, latency, time to first byte, and the response excerpt when present.
4. Run a manual check after mitigation to check recovery.

The primary Run check action creates a diagnostic record. It does not affect monitoring statistics or incidents. The adjacent alert action evaluates alert signals.

Coordinate

Move the incident through your team’s workflow statuses. Add comments for discussion. Add checkpoints for durable updates that responders must scan later.

Editors can create, rename, and remove workflow statuses. Every team has a default workflow status. Related incidents can be merged when several signals describe the same event.

Use a checkpoint for a concise update. The current interface calls checkpoints Public updates. Status page and integration delivery are not available yet. Keep required customer communication in your approved communication channel.

Resolve

You can enable automatic recovery when monitoring confirms that the endpoint recovered. You can also resolve an incident manually when technical health returned but response work continues.

Before resolving, record what changed. Confirm that affected endpoints are healthy. A concise final checkpoint makes the incident useful during review.

Reopen and merge

Reopen an incident when the response work must continue. Resolve it again after you confirm recovery.

Merge incidents when they describe one event. A merged incident with several affected endpoints cannot use automatic recovery.