PagerDuty's US region had a 15 minute incident starting at 01:24 UTC, touching nine components at once including SMS, Voice, Email and the REST API. The fault sat on PagerDuty's side, not yours.
Started
01:24 UTC
Duration
Lasted 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: SMS (US), Incident Workflows (US), Voice (US), Email (US), Web Application (US), Push (US), Events API (US), Responder Requests (US), REST API (US)
What happened?
PagerDuty logged a single incident on 27 September 2026, starting at 01:24 UTC and lasting 15 minutes. The component list affected is wide: SMS (US), Incident Workflows (US), Voice (US), Email (US), Web Application (US), Push (US), Events API (US), Responder Requests (US) and REST API (US), nine components in total. That spread suggests something shared underneath these services wobbled rather than each one failing on its own, but PagerDuty's status page does not say what that shared piece was. The only entry on record is titled "Issue Identified", and no further updates were filed before the incident closed, so there is no resolution note, no root cause statement and no post-mortem to point to. No user reports were filed during the window, which for a 15 minute fault in the middle of the night UTC is not unusual. Over the past 90 days PagerDuty has logged 12 incidents with a median duration of 1 hour 12 minutes, so this one closed well under that median. Across all time PagerDuty has recorded 299 incidents, averaging 3.9 a month, so a short incident like this one is closer to the norm than the exception for this provider. With nothing published beyond "Issue Identified", you are left with the timestamp and the component list as the full extent of the record.
Learning
PagerDuty's own component list names nine services as affected, but when an incident resolves in 15 minutes with no updates in between, you are relying entirely on the vendor's say-so for what actually happened and for how long. If your own endpoints or integrations with PagerDuty looked fine during that window, that is not a contradiction: a short upstream wobble in their incident routing or API layer can come and go without ever touching whatever you were polling. Over a 30 day period UptimeRobot's own checks against PagerDuty logged 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 from different vantage points. That gap is normal and worth remembering: a vendor's status page reflects what they chose to disclose, an external probe reflects what actually responded over the wire. Neither view alone tells you the whole story about an outage that touches notification delivery, which is exactly the kind of failure you might not notice from your own side until a page doesn't arrive. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
