Resolve client incidents with a clear timeline

Automatic incident detection, response notes, status updates, and reports so clients see what happened and how fast you reacted.

No card required · 50 monitors free · No time limit

Incidents

What broke, why, when it started, and how long it took to recover.

All / Ongoing / Resolved
Active incidents
0
Open incident records
Down
0
Reachability failures
Failed checks
1
Reachable, but a check failed
Current problemsIncident history
StatusMonitorWhat happenedStartedDuration
Resolved https://checkout.acmecorp.com Connection timeout after 5000 ms 2026-08-10 15:14 8m
Incident #4182 Open monitor → War room (4 events) →

Detected15:14:47

Connection timeout after 5000 ms — no HTTP response

Alert sent15:14:49

Slack #client-alerts, Discord ops-room, 3 e-mail recipients

Still down 4 checks15:15:17 — 15:16:47

Retried from the monitoring origin, same result each time

Escalation sent15:19:49

No recovery after 5 minutes — escalated to the on-call rota

Recovered15:22:31

HTTP 200 in 268 ms — the incident closed itself and a recovery alert went out on every channel

Resolved mail.northwind-supply.com : 587 Connection refused on port 587 2026-08-10 14:12 41m
Resolved https://harborbooks.com HTTP 000 — no response from origin 2026-08-10 15:09 2m
Resolved https://api.acmecorp.com/v1/orders HTTP 502 Bad Gateway 2026-08-07 03:02 12m
Resolved https://acme-store.com HTTP 500 Internal Server Error 2026-08-05 18:27 4m
Resolved https://shop.northwind-supply.com Connection timeout after 5000 ms 2026-08-01 23:14 1h 06m

Incidents open and resolve themselves from your monitor checks — no setup, no manual bookkeeping. Only reachability failures become incidents; failed keyword and API checks stay separate.

Maintenance value

Why this matters
for client care

Each feature earns its place by making the client relationship easier to protect: fewer surprises, clearer proof, and faster explanations when something changes.

01

Automatic incident creation

When a monitor goes down, an incident is automatically created with all relevant context and timestamps.

02

One page per incident

Each incident opens on the cause — DNS resolution failed, 403 Forbidden, keyword not found — with a plain-language explanation of what that usually means, the timeline in order, and room for notes.

03

Public status communication

Communicate incidents automatically to your public status page. Keep your users informed without extra effort.

04

Post-incident analysis

Review the complete timeline after resolution. Analyze response times, downtime duration, and recovery patterns.

In the app

One monitor, open

Current status, the average over 24 hours, the last check, and seven days of response-time history on one screen. Rebuilt here in markup rather than photographed — the trace draws itself as you scroll it. The workspace is invented; the layout is the one the app draws.

Real examples

What clients and developers actually see

Concrete moments from the feature: setup, the signal that matters, and the client-facing proof that makes maintenance feel easy and valuable.

Detection · example data

checkout.acmecorp.com stopped answering

Three consecutive timeouts open an incident with the monitor, the reason and the clock.

Open incidents

1

Trigger

Unreachable

checkout.acmecorp.com

Connection timeout on 3 consecutive checks

Down

Opened

02:41 UTC, on the first failed check of the streak

Automatic

Public status page

The open incident appears on status.acmecorp.com

Visible
Open incident Notify the team

Incident detail · example data

The cause, then the timeline

Detection, delivery and what a human found, on the same page while it is still happening.

Open for

9 min

Updates

4

02:41 UTC

Monitor recorded a connection timeout

Detected

02:42 UTC

Telegram and e-mail alerts delivered

Alerted

02:46 UTC

Note: upstream payment provider returning 502

Note
Add a note Post-mortem

Resolution · example data

What the client is told afterwards

The incident closes on recovery with a downtime figure you can defend line by line.

Time to recover

9 min

Incident

Resolved

02:50 UTC

checkout.acmecorp.com answered HTTP 200 again

Recovered

Downtime counted

Reachability failure only, 02:41 to 02:50

9 min

Failed checks excluded

Keyword and API policy failures never inflate this number

Excluded
Incident timeline Close incident
Quick start

Setup for one client in seconds

Add the signal once, then let alerts, history, and reports build automatically.

Step 1

Monitors run automatically

Once you've set up your monitors, incident management is active.

Step 2

Incident is detected

On downtime, an incident is automatically created.

Step 3

Open the incident

The cause is the headline. Read the timeline, add a note.

Step 4

Incident is resolved

On recovery, the incident is automatically closed with a complete report.

FAQ

Frequently asked questions

Yes — as soon as a monitor stops being reachable, an incident is opened with the first event, and it closes itself on recovery. A failed check on a site that still answers (a missing keyword, a rejected API response, a certificate warning) shows as an Issue and alerts, but does not open a downtime incident.

Currently, incidents are created automatically based on monitor status. Manual incidents are on our roadmap.

Yes, open incidents are automatically shown on your public status page, keeping your users informed.

Everything else

Everything around the client website

Combine uptime, SSL, domains, incidents, alerts, teams, and reports into one maintenance workspace.

Make this part of your maintenance service.

Start with incident management and build client trust with real data. Free, no credit card required.

Create free account

No card required · 50 monitors free · No time limit