Railway Outage History
5 incidents recorded over the last 365 days, 5 of them resolved. Durations are measured from when PulsAPI first saw the problem to when it cleared, which is usually longer than the vendor's own figure.
Every Recorded Railway Incident
| Date | Incident | Duration | Status |
|---|---|---|---|
| May 1, 2026 | Central Station login issues | 2257h 28m | Resolved |
| Apr 29, 2026 | Domain provisioning is heavily delayed | 2313h 9m | Resolved |
| Apr 26, 2026 | Degraded Build Performance | 2374h 41m | Resolved |
| Apr 24, 2026 | Railway dashboard unavailable. | 2428h 17m | Resolved |
| Apr 24, 2026 | Railway dashboard unavailable. | 2430h 35m | Resolved |
How to Read This Railway Incident Log
Each row is an incident PulsAPI observed, not a summary written afterwards. The duration is wall-clock time between the first failing check and the first clean one, so it includes the window before Railway acknowledged anything. Vendor post-mortems typically measure from acknowledgement, which is why their numbers are usually shorter.
Incidents still open have no duration yet and are listed as ongoing rather than being given a running total. The archive covers the last 365 days; anything older has aged out of the window rather than never having happened.
The longest single Railway outage in this window ran 101d 6h, against a mean recovery of 98d 8h. If you depend on Railway in a customer-facing path, the longest figure is the one to design around. The mean is what happens on a normal bad day; the maximum is what happens on the worst one.