How AI Agents Help with Website Incident Response

An AI agent in website incident response is software that takes a monitoring alert, gathers related signals, and proposes a cause. Some agents stop there. A few, such as PagerDuty's SRE Agent, can also run a remediation you approved in advance. The agent does not replace the person on call. It shortens the reading they would otherwise do by hand.

What an agent actually does when a site breaks

A website check fails, or a person reports that a page is down. Someone still has to decide whether that is an incident. PagerDuty's incident response docs define an incident as an unplanned disruption or degradation of service that is actively affecting its own customers' ability to use PagerDuty. They say the response can start from automated monitoring or from a person.

From there, the useful work splits into four jobs:

1. Gather. Pull the failing check, recent deploys, certificate state, and DNS record history into one place.
2. Sort. Separate a single failed check from a pattern, such as every monitor in one region failing together.
3. Explain. State a likely cause and the evidence for it, so the on-call person is not starting from a blank page.
4. Act, only if approved. Run a script the team already allowed, such as a rollback or a certificate renewal, and record what ran.

PagerDuty's own response guide does not use a five-phase model. Its public docs group the work as before, during, and after an incident, and name roles rather than phases: Incident Commander, Deputy, Scribe, subject-matter expert, and liaisons for customers and internal teams (During an Incident). The commander looks for an obvious cause, such as a recent deployment or a traffic spike, delegates the repair, and declares the incident over once the service has recovered. "Resolve" there is an instruction, not a phase name.

What current products do, and what they do not

Two vendors publish a concrete description of an agent. Treat marketing percentages on those pages as advertising, not as a result you can expect.

Datadog Bits Investigation is documented as an autonomous agent that investigates production issues end to end. It forms hypotheses, gathers telemetry, and reasons from that data so an on-call engineer can pinpoint a cause (Bits Investigation). The docs describe investigation. They do not say the agent applies a fix. It is not available on Datadog's government sites.

PagerDuty sells four generally available agents, coordinated by PagerDuty Advance (AI agents):

• The SRE Agent detects, triages, and diagnoses incidents, and can perform remediation you have approved. It looks for related and past incidents.
• The Scribe Agent captures incident meetings and channel conversations, and makes that record available for status-update drafts and the post-incident review.
• The Shift Agent flags clashes between time off and on-call shifts.
• The Insights Agent looks across tools for trends.

Those agents are an add-on. PagerDuty says customers on Professional, Business, or Enterprise Incident Management plans buy AI credits, and some features need the AIOps product.

Neither product is a website monitor. They sit on top of alerts that a monitor, a log pipeline, or a person already produced.

Where a website monitor fits

An agent is only as useful as the alert it receives. A status-code check tells you the server answered. It does not tell you that the page is blank, the certificate expires tomorrow, or the DNS records changed overnight.

Visual Sentinel is the monitoring side of that split, not an incident-response agent. See Visual Sentinel vs UptimeRobot and Visual Sentinel vs Pingdom for how the checks compare, and more articles for incident-response reading. It checks a site on a schedule and sends an alert when a check fails. It does not diagnose a cause, and it does not run a repair. Performance Monitoring reports page speed from lab tests, including LCP and CLS. Website Checker is a one-off check of reachability, response time, DNS, and TLS. It does not compare page content. DNS Checker and Speed Test are the same kind of manual check.

What it can hand an agent, or a person, is specific:

• Uptime. Uptime Monitoring records whether the URL answered, and how long it took. Business and Agency check as often as every minute. Solo and Starter check every 5 minutes.
• Expected text. Every plan, including Solo, can fail a check when a phrase you set is missing from the page. That catches a 200 response that is actually an error page.
• SSL. SSL Monitoring sends expiry reminders at 13, 3, and 1 days by default, so a certificate failure is a planned renewal rather than an outage. SSL Checker inspects the certificate that is deployed now.
• DNS. DNS Monitoring snapshots records (A, AAAA, MX, NS, TXT, CNAME) every 6 hours. A change is a record you can compare. It is not an instant propagation reading.
• Visual. Visual Monitoring compares screenshots against a baseline, default viewport 1920x1080, so a broken layout can alert even when the URL returns 200.
• Content rules. Content Monitoring must-contain and must-not-contain keyword rules start on Starter, not on Solo.

Checks run from Europe and the US. Alerts go to email, Slack, Discord, Microsoft Teams, Telegram, PagerDuty, Opsgenie, webhooks, WhatsApp, and the mobile app. There is no SMS and no phone call. API keys, which an outside agent would use to read checks, come with every paid plan.

A practical handoff: the monitor alerts PagerDuty (or posts to a webhook your own agent reads), and the agent opens with the check result, the last screenshot, and the last DNS snapshot already attached. The person on call then confirms the cause before anything is changed in production.

How to use an agent without letting it guess

PagerDuty's during-incident page tells subject-matter experts to suggest fixes and not to take action unless the commander says so. The same rule should bind an agent.

• Approve a short list of actions in advance. A rollback of the last deploy, a restart of one service, or a certificate renewal you already tested are reasonable. A database migration is not.
• Make the agent show its evidence. A useful report names the check that failed, the deploy that landed just before, and the record that changed. A one-line "root cause" with no evidence is not actionable.
• Keep a person as Incident Commander. The agent can hand you the notes for a status update. PagerDuty's Scribe Agent captures incident meetings and channel conversations and makes that record available for the draft. Publishing the update, and telling customers the incident is over, stays a human decision.
• Test the action on a staging target first. An auto-remediation that has never run will run for the first time during the outage.
• Review what ran. Keep the action log. After the incident, compare the agent's suggested cause with what actually fixed it, and delete approvals that were wrong.

Mean time to resolve can drop when triage notes write themselves and an approved rollback starts without a hunt for the runbook. It does not drop because a model was added. If the runbook is wrong, the agent runs the wrong fix faster.

What to ignore in vendor write-ups

A lot of pages attribute a lifecycle to PagerDuty that its response docs do not publish. If a guide names a discover phase, a diagnose phase, or a five-phase model, it is not quoting those docs. Use the before, during, and after pages, and the role steps, instead.

The same caution applies to detection rules stated as if they were universal. A load-time limit or a downtime length is a threshold you choose for that site. It is not a property of agents. Set it from your own baseline, then raise it if healthy traffic trips it.

Visual Sentinel's own checks are a feed, not a brain. Point an agent at the alerts if you have one. If you do not, the same alerts are enough for a person to start the during-incident steps: join the channel, name a commander, look for the obvious cause, and delegate the repair.

Run a website of your own? Read about keeping watch over your own website, so an alert tells you when something on it breaks.