Summary

  • Linode has scheduled Cloud Manager, API and CLI maintenance for 04:00–05:30 UTC on 19 August. Customers will not be able to create, boot, migrate, back up, shut down or otherwise administer instances during the window.
  • The provider expects running Linodes and Kubernetes workloads to continue, but the Kubernetes API, autoscaling, storage attachment and other API-dependent changes will be unavailable. That separates service continuity from the ability to control a service.

Linode is preparing to remove its cloud control surface for 90 minutes while trying to leave the running infrastructure underneath it untouched.

The official maintenance notice schedules the work for 04:00 to 05:30 UTC on 19 August 2026. During that interval, the company says Cloud Manager, its API and command-line interface will be offline. Customers will be unable to log in or perform administrative actions including creating, removing, booting, migrating, backing up or shutting down Linodes.

The notice draws an unusually clear line between the control plane and the data plane. Linode says running instances and related services will not be disrupted. A virtual machine already serving traffic is therefore expected to remain available. The customer will, however, lose the normal commands used to change that machine's state.

That difference becomes more consequential for Linode Kubernetes Engine. The Kubernetes API is included in the maintenance impact. Linode lists autoscaling, recycling, rebooting, attaching or detaching persistent volumes, provisioning NodeBalancers and creating clusters among the dynamic functions that will stop. Existing cluster nodes and running workloads are expected to continue.

This is not the same as a workload outage. It is a planned interval in which an application may stay online while its operator cannot respond in the usual way to changing demand, a failed node, a storage requirement or a load-balancing change. A team that has already provisioned enough capacity may notice little. A team relying on a scaling event or an urgent control-plane action during the window has a narrower operating margin.

The support path is also constrained. Linode says its ticket system will be unavailable. Telephone support will remain reachable, but support staff will not be able to authenticate customers or act on Cloud Manager or API issues during the maintenance. New account requests and pending account authentication will also pause.

The shared dependency is consistent with Linode's normal product design. Its Cloud Manager overview says the web interface is built entirely on the public API, while its CLI guide describes the command-line tool as an API wrapper. The API reference lists instances, LKE clusters, block volumes and NodeBalancers among the resources it manages. Linode's LKE operating guide separately distinguishes the Linode infrastructure API from the Kubernetes API used for cluster entities.

The official record associates the maintenance with Cloud Manager and API plus 43 named regions across North America, Europe, Asia-Pacific, Latin America and Africa. At 01:13 UTC on 19 August, those components were shown as operational and the maintenance status remained scheduled.

That timing boundary matters. Linode published the notice on 9 July, but the operational event is the 19 August window. The notice does not disclose the underlying change, technical cause or rollback plan. It does not prove that the work has started, that it will finish by 05:30 UTC, or that the provider's expectation of uninterrupted workloads has been independently measured.

Customers can act on the stated boundary without inventing an outage. Time-sensitive instance changes should be completed before 04:00 UTC. Teams using LKE can check whether near-term scaling, node replacement, storage attachment or load-balancer changes depend on the unavailable APIs. Recovery plans should also identify what can be done from inside a running workload when the provider's management plane cannot accept a command.

The decisive update will be the next one on the status page: whether maintenance enters progress on time, whether management access returns by 05:30 UTC, and whether Linode records any residual restriction after the window.

Source