On 25 September 2026, Linode's Cloud Manager and API went down for 1h 14m starting at 15:09 UTC. If you rely on the dashboard or API to manage your infrastructure, that window was Linode's fault, not yours.
Started
15:09 UTC
Duration
Lasted 1h 14m
Source
IsDown
Next time
Linode 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: Linode Manager and API
What happened?
Linode opened a single incident at 15:09 UTC, titled "Service Issue - Cloud Manager and API". The first update said the team was investigating a service issue affecting the Cloud Manager at cloud.linode.com and the API, and warned that some users might have trouble accessing these systems. That is the only component Linode listed as affected, there's no mention of the underlying compute, storage or networking layers that actually run your workloads. At 16:21 UTC, 1h 14m later, Linode marked the incident resolved, stating they hadn't observed any additional issues with the Cloud Manager or API. No root cause was given in either update, so why the Manager and API broke is not on the record. Linode's own status page carries only these two updates for the whole day, one opening and one closing, with nothing in between describing scope, affected regions or number of users hit. No user reports were filed during this window. Over the past 90 days, Linode has logged 20 incidents with a median duration of 3 hours 60 minutes, so this one resolved faster than typical. Across all time, Linode averages 7.6 incidents a month across 585 recorded incidents, which gives some sense of how often this kind of filing shows up on their status page.
Learning
This incident hit the Cloud Manager and API, the control plane you use to configure and inspect your Linode resources, not the compute instances themselves. That distinction matters: your own uptime checks against your running services could have stayed green the whole time, because your servers kept serving traffic even while the dashboard and API that manage them were unreachable. UptimeRobot's own 30 day data for Linode shows 5 incidents with a median duration of 5h 10m, considerably longer than the 1h 14m this single event lasted, which tells you that control plane disruptions here aren't rare and can run much longer than this one did. If you build automation that depends on the API, for provisioning, scaling or monitoring changes, that dependency breaks even when nothing is wrong with your actual infrastructure. Watching only your own endpoints won't catch this kind of failure because the fault sits one layer up, in the provider's management surface rather than your product. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
