Heroku, which sits under parts of Salesforce's infrastructure, had a logging fault lasting 1h 33m on 24 September 2026. The problem was on Heroku's side, in router logs for Common Runtime customers in the US, and the fix came from their own engineers.
Started
14:55 UTC
Duration
Lasted 1h 33m
Source
IsDown
Next time
Salesforce 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.
What happened?
The incident started at 14:55 UTC, though Heroku's first update says the underlying trouble began at 13:31 UTC on the same day. Some Common Runtime customers in the US region began losing application logs intermittently. By the 15:51 UTC update, Heroku narrowed the description: it was router logs being dropped in a subset of US regions, not app logs, which it said were unaffected. That distinction matters if you were trying to work out whether your own app was broken or whether the logging pipeline underneath it was the problem. At 16:10 UTC, Heroku reported the issue fixed and said it was monitoring, with all router logs being delivered successfully again. The whole episode ran 1 hour and 33 minutes from first report to resolution. No components are listed as affected in Heroku's status breakdown for this incident. There were three updates in total, and no further filings have appeared since the fix was confirmed. No user reports were filed during this window. Heroku's status page does not explain what caused the log delivery to intermittently drop, only that it was fixed. One filing from a vendor like this carries the detail they chose to publish, not necessarily the full picture of what happened internally. For context, Heroku and Salesforce's broader infrastructure has logged 127 incidents in the past 90 days, with a median duration of 2 hours 31 minutes, so this one resolved faster than typical.
Learning
This incident was a logging problem, not a request-serving outage, so your application itself likely kept running while its router logs silently dropped for over an hour. That is exactly the kind of fault an uptime check against your own endpoint will not catch, because your app answering requests normally and your app's logs being intact are two different layers. If you rely on logs for debugging, billing, or compliance evidence, a gap like this can go unnoticed until you go looking for data that was never written. Watching your own endpoints tells you whether your product is reachable, not whether the infrastructure underneath it is behaving as expected. Over the last 30 days, providers in this category have logged 39 incidents with a median resolution time of 3h 17m, which gives a sense of how often this kind of thing happens and how long it typically takes to clear. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
