Cases8 cases

5 to 8 of 8

1. IL-0378 All Cloudflare R2 object writes and about 35% of reads failed when the R2 Gateway could not authenticate to storage

   Cloudflare2025

   Symptoms

   From 21:38 UTC on 21 March 2025, Cloudflare R2 object storage returned errors for 1 hour and 7 minutes: all object writes failed and about 35% of object reads failed globally. R2 global availability alerts fired at 21:45 UTC, at a 2% error budget burn rate.

   Credentials unavailableHigh error rate

   Trigger

   During a routine rotation of the credentials the R2 Gateway Worker uses to authenticate with the storage infrastructure, the new credentials were deployed to the Worker of the default environment instead of the production Worker, and the old credentials were then removed from the storage infrastructure at 20:37 UTC.

   Root cause

   Operator error

   Component

   Object storage

   Contributing factor

   Unverified assumptionMonitoring blind spotChange with a delayed effect

   Detection

   R2 global availability alerts fired at 21:45 UTC, seven minutes after impact began, at a 2% error budget burn rate, and the R2 engineering team turned to operational dashboards and logs.

   Remediation

   • Deployed the new credentials to the production R2 Gateway Worker, which restored R2 availability

   Action items

   • Add logging tags with the suffix of the credential ID the R2 Gateway Worker uses
   • Require confirmation that the new token ID suffix matches storage infrastructure logs before deleting the old token
   • Run key rotation through the hotfix release tooling, which enforces the environment, instead of manual wrangler commands
   • Write the two-person validation of these changes into the standard operating procedures
   • Extend the closed loop health check system to test new keys, report their status through alerting and confirm global propagation before releasing the gateway Worker
   • Add observability views of upstream success rates that bypass caching

   Lessons

   Because the deletion of the old credentials took effect gradually, availability metrics were a poor way to confirm the change. Cloudflare said the team should have checked directly which token the R2 Gateway service was using to authenticate with the storage infrastructure instead of relying on those metrics.

   View case
2. IL-0343 DNS names under digitaloceanspaces.com stopped resolving, breaking Spaces, Container Registry and the Control Panel

   DigitalOcean2024

   Symptoms

   From 22:38 UTC on 28 November 2024, DigitalOcean's Cloud Control Panel stopped loading for customers, and sign-up and log-in failed. DigitalOcean declared the incident from monitoring and customer reports, an internal alert fired at 22:44 UTC, and Spaces buckets and the services that depend on them began to fail intermittently.

   DNS resolution failuresHigh error rateImage pull failures

   Trigger

   At 22:38 UTC on 28 November 2024, DigitalOcean's domain registrar, Network Solutions, made an update to the digitaloceanspaces.com domain that added an Extensible Provisioning Protocol (EPP) clientHold status code to it.

   Root cause

   Dependency failure

   Component

   Domain registrar and registryObject storageContainer registry and its credentials

   Contributing factor

   Cache-masked failureMonitoring blind spot

   Detection

   DigitalOcean declared the incident at 22:38 UTC based on monitoring and customer reports that the Cloud Control Panel would not load. An internal alert detected the issue at 22:44 UTC, and the first customer contact about the Control Panel came at 22:57 UTC.

   Remediation

   • Deployed a change that brought the Cloud Control Panel back online
   • Contacted Network Solutions to have the clientHold removed
   • Escalated to Verisign executives, the .com registry, until the clientHold was removed

   Action items

   • Work with Network Solutions to understand why the clientHold was applied to the domain
   • Review other domain registrars as possible new homes for DigitalOcean's domains
   • Review monitoring and alerting to detect registrar-imposed changes and DNS resolution problems sooner

   View case
3. IL-0535 An internal Kinesis Data Streams cell in US-EAST-1 degraded, raising errors in CloudWatch Logs, S3 events and Lambda

   Amazon Web Services2024

   Symptoms

   From 2:45 PM PDT on July 30th, 2024, several AWS services in the Northern Virginia (US-EAST-1) Region had higher latency and error rates: CloudWatch Logs, Amazon Data Firehose, the event framework that publishes Amazon S3 events, Amazon ECS, AWS Lambda, Amazon Redshift and AWS Glue. All of them used one internal cell of Amazon Kinesis Data Streams, whose requests had started to see elevated latency and errors.

   High latencyHigh error rateMonitoring outageProbe failures

   Trigger

   At 9:09 AM PDT on July 30th a routine deployment started in one Availability Zone of the Kinesis cell, and taking hosts in and out of service during the deployment set off the failure.

   Root cause

   Software defect

   Component

   Message brokerServerless function platformObject storage

   Contributing factor

   Unrepresentative stagingAutomation amplification

   Remediation

   • Deployed a change that shed load by reducing incoming stream volume from less time-sensitive internal workloads
   • Added capacity to the subsystem that provisions secure connections for Kinesis requests
   • Added more capacity at 6:32 PM PDT to further improve connection provisioning

   Action items

   • Keep the added connection provisioning capacity, load-shedding tooling and changed connection limits in place in US-EAST-1
   • Apply the same changes in every other region that has cells with the new Kinesis Data Streams architecture
   • Update the cell management system to better manage the workload that triggered the issue

   View case
4. IL-0382 Linode Object Storage in Newark and Atlanta returned 503 Slow Down to all clients under very high inbound traffic

   Linode2022

   Symptoms

   On 19 and 20 October 2022, Linode Object Storage in Newark and Atlanta slowed down, became less available and rate limited many requests with "503 - Slow Down" HTTP responses, after the clusters received extremely high inbound traffic in both request count and bandwidth.

   High error rateMemory pressure

   Trigger

   Extremely high inbound traffic, in both total requests and throughput, reached the Newark and Atlanta Object Storage clusters on 19 and 20 October 2022.

   Root cause

   Capacity exhaustion

   Component

   Object storage

   Contributing factor

   Unpatched known bugExcessive blast radius

   Remediation

   • Fixed the edge rate limiting so it enforces the advertised 750 requests per second per bucket
   • Adjusted Ceph tunables to stop runaway memory use during high-pressure storage events
   • Moved internal Object Storage components hit by resource contention to less busy, higher-performance infrastructure
   • Adjusted performance tunables on internal components and back-end clusters so customers were not rate limited too early

   Action items

   • Refine throughput and bandwidth throttling
   • Scale up the internal Object Storage infrastructure to spread load more efficiently
   • Look for further hardware performance improvements for the internal Object Storage infrastructure
   • Tune the load balancing algorithms to avoid hotspots in the clusters

   Lessons

   Linode's per-bucket rate limiting at the edge is meant to keep excess load off the back end; when it works as intended, the back-end limits, which throttle every client alike, should never come into play.

   View case

By root cause6