Vendor reports: operationalOpen · vendor status “monitoring”Official status API
Service Issue - Block Storage (BR-GRU)
Reported by Linode (Akamai) · Cloud & Infrastructure · source last read just now
- Vendor start
- Oct 28, 2026, 20:17 UTC
- Vendor's clock
- Resolved
- Not yet
- Still open
- First seen by Statuswall
- Before tracking began
- Statuswall's clock
- Duration
- Not available
- Needs both vendor times
Affected scope
Not stated by the vendor
The vendor's feed gives no region for this incident. It is not assumed to be global.
Potential relevance
Linode (Akamai) is not in your stack. Follow it to see whether reports like this fall inside the regions you use.
What to check on your side
Verification steps only. Statuswall cannot see your systems.
- Check resource health in the regions named by the vendor, and in your other regions for comparison.
- Separate control-plane actions (deploys, scaling, console) from data-plane traffic: they often fail differently.
- If you run multi-region or failover, confirm what your own health checks report before acting.
- Check error rates, latency and timeouts in your own monitoring for requests that depend on Linode (Akamai).
- Look at synthetic checks and alerts that exercise Linode (Akamai).
- Compare with recent deploys on your side, so a coincidental change is not blamed on the vendor.
- Follow the vendor's official incident page for scope changes and resolution.
Timeline
Vendor times come from the vendor. “Seen by Statuswall” times are when Statuswall noticed a change, which can lag the vendor by a few minutes. Statuswall does not store the vendor's update text; read it on the official page.
- Oct 28, 2026, 20:17 UTCVendor-reported startVendor time
No changes observed yet. Statuswall began recording changes on incidents in November 2026.