Linode status

How we check Linode

We watch api.linode.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host behind the cloud manager and the CLI, pinning the response an unauthenticated request receives rather than expecting a 2xx from an API root. Your own instances answer on their own addresses and their health is your responsibility, so probing one would report on your server rather than on Linode.

What is Linode?

Linode is a cloud infrastructure provider now operated by Akamai, and it occupies a particular niche: straightforward virtual machines with predictable pricing, aimed at developers who want a server rather than a platform. A lot of production runs on it, much of it belonging to small teams for whom a single instance is the whole application, which is why an incident there tends to be total rather than partial for the people affected.

The first distinction worth keeping straight is between the control plane and the machines. The cloud manager and the API create, resize, reboot, and reconfigure instances. The instances themselves run without them. When the control plane is unavailable you cannot make changes, but the servers keep serving and your users see nothing, and when a datacentre has a network or power event the opposite is true. Conflating them wastes attention on the wrong emergency.

The second is scope. Linode runs datacentres in many places and incidents are usually confined to one, so whether an announced event matters to you depends entirely on where your instances live. This is also the reason reports during an event contradict each other so reliably. Anyone with a single instance in a single region is exposed to that region's bad days, which is not a criticism of the provider so much as an accurate description of what a single server can promise.

Most of the time, though, an unreachable Linode is not Linode's fault, and it is worth saying plainly because the instinct runs the other way. A disk that filled with logs, a process killed by the out-of-memory killer that took the web server with it, an unattended upgrade that rebooted into a kernel that does not boot, a firewall rule tightened during unrelated work: these account for far more downtime on small deployments than platform incidents do. The out-of-band console is the tool for all of them, because it works when SSH does not, and knowing it exists before you need it saves an unpleasant hour.

The Akamai acquisition changed the operational context more than the day-to-day product. Incidents may be published under Akamai's name, the network underneath is Akamai's, and the Linode name survives mostly in hostnames and habits. For a monitoring page the practical consequence is knowing where to look when something is wrong, which is why the official channels below matter as much as our own reading.

Frequently asked questions

Is Linode down right now?

Check the board above; it reflects our own probes against Linode's API from all five of our regions, refreshed every couple of minutes. This measures the platform's control plane rather than whether your individual instance is running.

My Linode is unreachable but this page shows Linode up. What should I check?

Check the instance itself, because a single server going down is nearly always about that server. A full disk, a process killed for memory, a firewall rule that locked out SSH, or a kernel upgrade that did not come back cleanly all produce an unreachable host while the platform is healthy. Lish, the out-of-band console in the cloud manager, gets you a session that does not depend on the network path that broke.

Does a Linode incident affect all datacentres?

Rarely. Incidents are normally scoped to a single datacentre, so the region your instances run in decides whether a published incident is relevant to you at all. Two customers can report completely different experiences during the same event without either being wrong.

Is the cloud manager being down the same as my servers being down?

No. The cloud manager and API are the control plane, and your instances keep running when it is unavailable. What you lose is the ability to reboot, resize, create, or reconfigure anything, which is disruptive to operations and invisible to your users.

What changed now that Linode is part of Akamai?

The service is operated by Akamai and is branded as Akamai Cloud Computing, while the Linode name persists in the API hostname, the tooling, and everyday usage. For the purposes of this page it means incidents may be published under Akamai's name, and that the underlying network is Akamai's rather than the smaller one Linode ran independently.