Akamai's own status page reports a short fault in Akamai Control Center and Configuration Deployment on 30 September 2026, affecting activation of delivery configurations and access to Identity Manager. Akamai says the issue ran from 14:13 UTC to 14:34 UTC, with a single resolved update posted at 15:03 UTC. The fault sat in Akamai's management layer, not in the edge network that actually serves your traffic.
Started
15:03 UTC
Duration
Reported resolved
Source
IsDown
Next time
Akamai 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.
What happened?
Akamai logged one incident on 30 September 2026, titled "Akamai Control Center and Configuration Deployment Issues". The filing describes errors when activating delivery configurations in Property Manager, and an inability to access Identity Manager inside Akamai Control Center to manage users. Akamai states the issue lasted between 14:13 UTC and 14:34 UTC, but the update itself was not posted until 15:03 UTC, and it arrived already marked resolved. There is only one update on record for this incident, so everything known about it comes from that single filing. Akamai points customers to its community portal or to Akamai Support for further detail, but no separate post-mortem has been published. No components are listed as affected in the record, and no user reports were filed during the window. Over the preceding 90 days Akamai logged 27 incidents with a median duration of 17 hours 7 minutes, and its all-time rate runs at 6.3 incidents a month, so a single-update incident resolved within 21 minutes is short by Akamai's own history. The affected systems, Control Center and configuration deployment, are management and administration tools used to push config changes and manage user access, not the edge delivery network that serves cached content and routes traffic. That distinction matters for how this incident shows up, or doesn't, in external monitoring.
Learning
UptimeRobot's own probes watched edge-reachability across EU and NA regions through this window and recorded 100% uptime at 24 hours, 7 days and 30 days, with this incident not registered against any probe check. Both readings are correct. The fault lived in Akamai's control plane, the dashboard and API layer used to activate configurations and manage identities, while the edge network that actually serves cached requests kept running normally throughout. An external check that pings your delivery endpoint has no way to see a failure in a configuration management console, because the two systems are separate and only one of them touches live traffic. If your product uses Akamai and you only monitor your own endpoints, this kind of incident passes you by entirely until you try to push a config change and find it won't activate. Over 30 days UptimeRobot's own checks have caught 11 incidents on Akamai with a median duration of 13h 48m, a different shape to what Akamai's own status page reports in the same period, which tells you the two measurements are tracking different layers rather than disagreeing. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
