# Using Atlas with PagerDuty in 2026 > Atlas reads triggered PagerDuty incidents, their services, and log entries, then traces the page back to a commit and drafts the postmortem timeline. Atlas reads triggered PagerDuty incidents, their services, and log entries through PagerDuty's official MCP server, then traces the page back to a commit and drafts the postmortem timeline. Register it over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp, and leave --enable-write-tools off to keep the server read-only. ## What Atlas does during a PagerDuty incident Atlas reads triggered PagerDuty incidents, their services, and log entries through PagerDuty's official MCP server, then traces the page back to a commit and drafts the postmortem timeline. In 2026 an on-call engineer can ask which service is paging without opening a browser. On-call work is mostly correlation under time pressure. PagerDuty knows what fired and when. Git knows what changed and when. The person in the middle is the one doing the joining, usually at an hour when joining things is hard. The PagerDuty MCP server hands that correlation to Atlas: it reads the triggered incident, its service, and its log entries, then looks for the commit that lines up. What comes back is a suspect, a proposed fix, and a timeline you can argue with. ## Adding PagerDuty's MCP server over stdio Add PagerDuty's official MCP server over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp. That 1 command is the whole install in 2026, because the uvx runner fetches pagerduty-mcp on demand and nothing has to be installed globally first. The credential is a PagerDuty user API key, exported as PAGERDUTY_USER_API_KEY and passed through with --env. Because the server runs as a local stdio process launched by uvx pagerduty-mcp, no PagerDuty data leaves through a third party endpoint and the key stays on your machine. Register it once and the entry persists in atlas.json, which is also where you will edit the command array later if you decide to enable write tools. ## Read-only by default, write tools by choice Leave the --enable-write-tools flag off and PagerDuty's MCP server stays read-only, which is the correct default for most teams in 2026. Add that 1 flag to the pagerduty command array in atlas.json only when you want Atlas to acknowledge or resolve incidents. Acknowledging and resolving a PagerDuty incident are consequential actions: they change who else gets woken up. The default in this setup is read-only, and that default is correct for most teams. If you do want Atlas to acknowledge or resolve, the change is explicit and reviewable: add --enable-write-tools to the pagerduty entry's command array in atlas.json. Keeping the flag out of the initial registration means nobody enables incident writes by accident. ## EU accounts and PAGERDUTY_API_HOST EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com when registering the pagerduty-mcp server with Atlas. Skip that 1 environment variable and an EU account's triggered incidents will not show up, which looks like a quiet on-call queue rather than a misconfiguration. PAGERDUTY_API_HOST is easy to forget because everything else about the setup succeeds without it. The server starts, atlas mcp list reports the entry, and the only symptom is that Atlas cannot see incidents you know are firing. If your PagerDuty account is in the EU, set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com alongside PAGERDUTY_USER_API_KEY, and verify before an incident rather than during one. ## The on-call loop: what is paging, and why Ask Atlas which service is currently paging, then have it pull the triggered incident's log entries and recent changes. Those 2 questions are the opening move of an on-call session in 2026, and PagerDuty's MCP server answers both without a dashboard. Start broad, then narrow. The first question, which service is currently paging, tells Atlas where to look. The second, pull the triggered incident's log entries and recent changes, gives it the evidence. Log entries carry the sequence of what PagerDuty observed. Recent changes carry what your team shipped. Together they are usually enough for Atlas to say which deploy is the likely cause, and to say it before you have finished reading the alert yourself. ## From suspect commit to incident timeline Let Atlas name the suspect commit, write the fix, and produce the incident timeline as a diff you review. Both artifacts come out of 1 session in 2026, assembled from PagerDuty log entries and recent changes rather than from memory days later. Postmortems are usually reconstructed days later from Slack scrollback and half remembered timestamps. Having Atlas produce the incident timeline from PagerDuty log entries while the incident is still live inverts that. You review the timeline as a diff, correct the parts it got wrong, and keep the parts it got right. The fix and the writeup come out of the same session, which is the only time anyone actually remembers what happened. ## Check the connection before you go on call Check with atlas mcp list that the pagerduty entry shows connected before an on-call session starts. Discovering a broken PagerDuty MCP connection during a live incident costs minutes nobody has, and the pre-flight check takes exactly 1 command. atlas mcp list prints the registered servers and their status. Run it at the start of a shift, not at the start of an incident. If the pagerduty entry is not connected, the usual causes are an expired PAGERDUTY_USER_API_KEY or a missing PAGERDUTY_API_HOST on an EU account, and both take a minute to fix when nothing is on fire. Treat the check as part of the handoff ritual. ## Setup 1. Add PagerDuty's official MCP server over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp 2. Leave the --enable-write-tools flag off for a read-only server, and add it to the command array in atlas.json only when you want Atlas to acknowledge or resolve incidents. 3. EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com 4. Ask Atlas which service is currently paging, then have it pull the triggered incident's log entries and recent changes. 5. Let Atlas name the suspect commit, write the fix, and produce the incident timeline as a diff you review. 6. Check with atlas mcp list that the pagerduty entry shows connected before an on-call session starts. ## FAQ ### how to connect Atlas to PagerDuty Run atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp to register PagerDuty's official MCP server over stdio, then verify it with atlas mcp list. ### how do I keep the PagerDuty MCP server read-only Leave the --enable-write-tools flag off. The server is read-only without it. Add the flag to the command array in atlas.json only when you want Atlas to acknowledge or resolve incidents. ### PagerDuty MCP server EU region setup EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com alongside PAGERDUTY_USER_API_KEY. Without it, an EU account's triggered incidents will not appear. ### can an AI agent trace a PagerDuty page back to a commit Yes. Atlas pulls the triggered incident's log entries and recent changes through PagerDuty's MCP server, names the suspect commit, and proposes the fix as a diff. ### can Atlas write a postmortem timeline from PagerDuty Yes. Atlas produces the incident timeline as a diff you review, built from PagerDuty log entries and recent changes rather than from memory. ### how do I check the PagerDuty MCP connection in Atlas Run atlas mcp list and confirm the pagerduty entry shows connected. Do it before an on-call session starts, not during an incident. ### can Atlas acknowledge or resolve a PagerDuty incident Only if you opt in. Add --enable-write-tools to the pagerduty command array in atlas.json. Without that flag the server is read-only. --- Canonical HTML: https://runatlas.sh/resources/integrations/pagerduty Source of truth: aeo_pages row `/resources/integrations/pagerduty` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.