PagerDuty's Incident Workflows feature was delayed for 1h 15m on 25 September 2026, affecting both the US and EU regions. The fault sat on PagerDuty's side, not in anything you run.
Started
13:43 UTC
Duration
Lasted 1h 15m
Source
IsDown
Next time
PagerDuty is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Incident Workflows (US), Incident Workflows (EU)
What happened?
PagerDuty logged a single incident starting at 13:43 UTC, titled "Issue Identified - Incident Workflows experiencing delays." It ran for 1h 15m and touched two components: Incident Workflows (US) and Incident Workflows (EU). PagerDuty's status page carries no further updates beyond that one entry, so there is no record of when the delays peaked or what specifically triggered them. No user reports were filed during the window, which means nobody on record logged a complaint while this was happening, not that it went unnoticed. PagerDuty's own history shows this kind of thing is not rare: 12 incidents in the last 90 days, with a median duration of 1 hour 12 minutes, so this outage ran close to typical length for this provider. Across all time PagerDuty has logged 299 incidents, averaging 3.9 a month. That rate puts a single 1h 15m delay in context: it is one entry in a long-running pattern, not an isolated event. With only one filing and no updates, there is not much to go on beyond the headline. PagerDuty has not published a post-mortem for this incident. The cause is not on the record.
Learning
When PagerDuty's own status page says "Incident Workflows experiencing delays," that is a statement about PagerDuty's backend processing, not about whether your webhooks or integrations reached PagerDuty successfully. Over the last 30 days, UptimeRobot's own checks against PagerDuty recorded 6 incidents, all resolved, with a median duration of 44m, a different number from PagerDuty's own 90-day median of 1 hour 12 minutes, because the two are measuring different things: PagerDuty's workflow engine internally versus the endpoints UptimeRobot actually reaches. A delay in incident workflows can sit entirely inside PagerDuty's processing pipeline, after your alert has already landed, which is exactly the kind of failure your own uptime checks on your own services would never surface. That is why the two readings are not a contradiction. Your monitoring covers your half, and UptimeRobot now watches the provider's half too, so next time something like this happens you know which side broke without guessing.
