Skip to main content
The DevOps employee investigates an alert. It reads what you have connected — metrics and logs, the error behind the alert, recent deploys and the on-call incident — and writes the likely cause, with each piece of evidence numbered and a plain statement of how sure it is. It proposes next steps: posting the investigation to the incident, a note and an acknowledgement on the PagerDuty incident, and a rollback or restart that your team runs. After an incident is resolved it drafts the postmortem. A fix is never run on your systems, even when approved, and nothing goes out without a person’s approval.
In beta, off unless your deployment has switched it on. Grafana Cloud, Datadog, Sentry, GitHub, PagerDuty and Jira can be connected with a token you create. None of them has yet been run against a real account. See AI employees.

​
How work reaches it

  • Sentry sends an alert rule’s notification, signed with your integration’s client secret.
  • PagerDuty sends incident.triggered (investigated) and incident.resolved (a postmortem to draft), signed with your webhook subscription’s secret.
  • Your monitoring, such as Grafana alerting, sends an alert with an API key (Send an alert).
  • A person hands one over on the DevOps page, or asks for a postmortem there.
The Sentry and PagerDuty addresses are shown beside each connection on the DevOps page. Each address names a connection, not your organisation, and only a request carrying that vendor’s valid signature is read. See Connect your tools.

​
What an investigation does

  1. Reads the evidence for the service the alert names: error rate and latency, recent log lines and recent deploys; for an alert from Sentry, the issue and its latest event — exception, release and stack frames; for one from PagerDuty, the incident and its timeline. Reads need no approval.
  2. Numbers each piece of evidence (E1, E2 …), quoting what the tool reported.
  3. Names a likely cause and says how sure it is. Confidence comes from which structured signals agree, never from what any text says: Even “high” is written as a hypothesis, with what would confirm or rule it out.
  4. Says what it did not read — a tool that is not connected, a service with no data — so a missing tool is never mistaken for a clean bill.
  5. Asks your knowledge for the runbook, when an assistant is set.
  6. Proposes next steps, each waiting for your approval.
Log lines, exception messages, file names and incident titles are quoted and never followed: a log line that says “roll back” is just a log line.

​
What it proposes

An approved rollback or restart is recorded and nothing is sent. No connection carries a fix to your systems. Nothing here resolves a PagerDuty incident: only a note and an acknowledgement, each approved by a person.

​
Postmortems

When PagerDuty reports an incident resolved — or when you choose Draft a postmortem beside an alert on the DevOps page — it drafts one:
  • Summary and impact: duration from the incident’s timeline, the peak error rate in the hour before the draft, urgency, and who was affected (left for you to fill in).
  • Timeline in UTC: deploys, the error-rate rise, when Sentry first saw the error, and PagerDuty’s own log entries.
  • Cause, with the same confidence statement, and the evidence.
  • Action items for your team to agree.
The draft waits in Approvals. Edit it there; approving files it as a Jira issue when Jira is connected. Without Jira nothing is sent, and you can copy or download it as Markdown.

​
Tools it can connect

Connect your tools has the steps for each.

​
Limits

  • It never runs a fix, and never resolves an incident.
  • The cause is a heuristic over structured signals. It says so, and says how sure it is.
  • Metrics and logs cover the last hour before the investigation or draft.
  • A Sentry issue is read only when Sentry sent the alert. An alert from elsewhere does not search Sentry.
  • PagerDuty’s US service region only (api.pagerduty.com); an EU account cannot be connected yet.
  • A self-hosted Sentry must be reachable from the internet over https; a private address is refused.
Last modified on November 7, 2026