---
title: From new monitor to post-mortem: one incident, worked with the WatchFor agent
description: One real incident, worked with the agent beside the dashboard: it creates the monitor, explains the failure, re-checks it live and drafts the post-mortem.
canonical: https://watchfor.io/blog/ai-agent-incident-start-to-finish
---

# From new monitor to post-mortem: one incident, worked with the WatchFor agent

2026-10-20 · WatchFor Team · Monitoring · ai, incidents, ssl, monitoring

One real incident, worked with the agent beside the dashboard: it creates the monitor, explains the failure, re-checks it live and drafts the post-mortem.

Most "AI for incident response" demos are a chat box that summarises
yesterday's alerts. We wanted to see what it looks like when the assistant
sits next to the dashboard and does the work with you: set something up,
watch it break, explain it, check it again right now, and write it up.

So we ran one case from start to finish in our demo organization, Acme, and
took a screenshot at every step. Every answer below is the agent's real
reply. Nothing was retyped or arranged afterwards.

One thing to be upfront about: we needed a failure we could show without
pointing at someone's real outage. So the target is `expired.badssl.com`, a
public test host that serves an expired certificate on purpose. The agent
didn't know that. It found out the same way it would on your site.

## Step 1: create the monitor in one sentence

The agent panel opens on the right and pushes the page over instead of
covering it, so the dashboard stays in view. We typed:

> Create an SSL certificate monitor for expired.badssl.com, checked every hour.

It didn't create anything yet. It worked out the monitor type and showed
what it was about to create: name, type, target, interval and location, with
**Approve**, **Decline** and **Edit**. Anything that changes your setup goes
through a card like this first.

![The Acme dashboard with the agent panel open on the right. The request "Create an SSL certificate monitor for expired.badssl.com, checked every hour" sits above a Create monitor card marked Needs your OK, listing name, type SSL, target, every hour, Vilnius, with Edit, Decline and Approve buttons](/blog/ai-agent-incident-start-to-finish-create.webp)

## Step 2: the card in the chat keeps watching

After **Approve**, the reply is a card for the new monitor, not a sentence
saying "done". At first it read **Pending** and "Running the first check…".

![The agent panel after approval: a card for expired.badssl.com with a grey PENDING badge and "Running the first check…", an Open monitor button, and the agent's note that default availability and certificate-expiry alerts are on](/blog/ai-agent-incident-start-to-finish-pending.webp)

We didn't type anything else. About a minute later the same card changed on
its own: the badge went from **Pending** to **Degraded**, and the first-check
line turned red: *TLS handshake failed: failed to verify certificate: x509:
certificate has expired*.

![The same card a minute later, unchanged conversation: the badge now reads DEGRADED in amber and the first-check line shows the TLS handshake failure for an expired certificate, while the dashboard's Firing now list does not show it yet](/blog/ai-agent-incident-start-to-finish-degraded.webp)

That is the difference between a chat that prints text and a chat with live
results in it. The card is wired to the monitor, so you learn about the
problem in the place you were already looking.

A moment later the failure was confirmed. The dashboard's **Firing now** list
showed a new critical incident for `expired.badssl.com`, and the card in the
panel moved to **Down**.

![The dashboard now shows 2 critical incidents; Firing now lists expired.badssl.com as Critical for 1 minute, and the agent's card for the monitor reads DOWN](/blog/ai-agent-incident-start-to-finish-firing.webp)

## Step 3: change it without opening a form

The panel offered follow-ups under the card. We typed one of them out:

> Alert me 14 days before the certificate expires.

Same pattern: an **Update monitor** card with the one field that changes,
"Expiry reminders: 14", waiting for an OK.

![An Update monitor card marked Needs your OK, showing the expired.badssl.com monitor with a DOWN badge and the change "Expiry reminders: 14", with Edit, Decline and Approve](/blog/ai-agent-incident-start-to-finish-edit.webp)

In a rehearsal run we had asked for something it couldn't do: checks every
5 minutes from three regions. It said SSL checks have a one-hour minimum and
left the monitor as it was. It didn't fake the change.

## Step 4: what's wrong, and since when?

We opened the incident and asked the obvious question.

> What's wrong here, and since when?

The panel shows the steps it took, **Opened the incident** and **Read recent
checks**, then the answer: the certificate served by `expired.badssl.com`
expired on 12 April 2015, so the TLS handshake fails verification. The
incident started at 18:18, and all four failed checks so far came from
Vilnius.

![The incident page for expired.badssl.com, Active Incident, Critical, with the Root Cause Analysis card on the left. In the agent panel: Opened the incident, Read recent checks, and the answer naming the April 12, 2015 expiry and the start time](/blog/ai-agent-incident-start-to-finish-identify.webp)

Notice where the date came from. The incident card itself says "Probe failed
to connect or returned an error". The agent read the check results under it
and pulled out the line that matters.

## Step 5: explain it like I'm not on call

The next question is the one a manager, a client or a support agent asks.

> Explain it in plain words: is it our server or the certificate, and what do visitors see?

The answer: it points to the certificate, not to the server being down. The
server answered, but its certificate expired, so visitors usually get a
browser security warning and may not reach the page at all. It also says
what the check can't tell you: it's about the certificate, not whether the
application behind it is healthy.

![The agent's plain-language explanation beside the incident: it's the certificate, not evidence the server is down; visitors will usually see a browser security warning; the check says nothing about whether the application behind it is healthy](/blog/ai-agent-incident-start-to-finish-explain.webp)

## Step 6: check it again, now

Most assistants in monitoring tools stop here, because all they can do is
read what was stored. The WatchFor agent can also run a check from our probe
fleet while you wait.

> Check the certificate live, right now, not from history.

It ran a live SSL check and showed the result as its own card: **Failed**,
the certificate has expired, measured from Vilnius in 276 ms. The reply ends
with "This is a current measurement, not historical monitor data."

![A live SSL certificate card in the agent panel: Failed, "The certificate presented by expired.badssl.com has expired (or is not valid yet)", from Vilnius in 276 ms, with the agent confirming the monitor remains down](/blog/ai-agent-incident-start-to-finish-live.webp)

Then we asked for the wider view.

> Is it the same from other regions? Run the full diagnosis — DNS, TLS, HTTP and ping.

It ran DNS, TLS, HTTP and ping in one go. DNS resolves. TLS finds an expired,
untrusted certificate and grades it F. HTTPS can't get a response because
validation fails. Ping gets no replies, which on its own doesn't mean the
host is down, because many hosts block ping.

![The agent's diagnosis reply: it ran from Vilnius only so it can't confirm other regions; DNS resolves, TLS found an expired untrusted certificate graded F, HTTPS failed validation, ping got no replies which alone doesn't mean the host is down](/blog/ai-agent-incident-start-to-finish-diagnose.webp)

It also told us what it couldn't do. The demo organization we used can only
reach probes in one city for this check, so the agent said it couldn't
confirm whether other regions see the same thing. On the full fleet, the same
diagnosis runs from up to three regions. We'd rather have that sentence than
a confident "it's down everywhere".

## Step 7: the post-mortem, drafted from what actually happened

> Draft the post-mortem for this incident.

It opened the incident, opened the post-mortem, and put a full draft
in a card for review: summary, impact, root cause, detection, resolution,
what went well, what could have gone better, and suggested action items.

![The post-mortem draft card in the agent panel, Needs your OK: Detection, Resolution with "Not known yet: what action will resolve the incident", What went well, What could have gone better noting the evidence doesn't show whether the test endpoint is intentional, and two Suggested action items](/blog/ai-agent-incident-start-to-finish-draft.webp)

Read the draft and you'll see the lines it refuses to make up. *Not known
yet: what action will resolve the incident.* *Not known yet: whether this
incident affected any users or production traffic.* Action items are marked
**Suggested**, not decided. It even noticed something we hadn't told it:
the evidence doesn't show whether this endpoint is meant to serve an expired
certificate, so one suggested action is to confirm that first. For a test
host, that's exactly right.

After **Approve**, the draft became a real post-mortem page: status **Draft**,
severity, the incident linked at the top, and the text ready to edit.

![The saved post-mortem page for expired.badssl.com, status Draft, severity Critical, title "Expired certificate on expired.badssl.com", with Summary, Impact and Root cause filled in, and the agent panel showing "Saved the post-mortem" with a link to it](/blog/ai-agent-incident-start-to-finish-postmortem.webp)

The judgement stays with you: why the certificate wasn't renewed, who was
affected, what you'll change. The draft saves the half hour of copying times
and error messages out of three screens. For what a good write-up needs, see
[The blameless post-mortem](/blog/blameless-postmortem) and
[drafting it from the incident timeline](/blog/write-the-postmortem-from-the-timeline).

## What this case shows, and what it doesn't

- **It asks before it changes anything.** Creating, editing and saving went
  through an approval card each time. Questions and live checks didn't need one.
- **Its cards are live.** The monitor card in the chat went from Pending to
  Degraded to Down while we did nothing.
- **It measures as well as reads.** The live check and the diagnosis ran
  against the target there and then, from the probe fleet. They weren't
  answered from stored history.
- **It says what it doesn't know.** One-hour minimum, one city in this demo,
  "not known yet" in the post-mortem.
- **It doesn't replace the person on call.** It won't renew a certificate or
  tell you which customer was hurt. It gets you to those questions faster.

Each turn showed its cost in the panel: one credit. The in-app agent is in
early access and is switched on per organization. Everything it did here goes
through the same tools your own assistants can use over our
[MCP server](/docs/api/mcp) and [live diagnostics API](/docs/api/diagnostics),
so you can build the same flow into Claude, ChatGPT or your own scripts.

If you'd rather start with the monitor than the conversation, an
[SSL certificate monitor](/ssl-monitoring) takes a minute to set up by hand,
and it catches the same expired certificate on its first check.

---

Canonical page: https://watchfor.io/blog/ai-agent-incident-start-to-finish · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt