Response Time Degradation

What to do

• Check whether your product depends on DatoCMS. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 0m it lasted.

  Anything that failed between 2025-04-09 10:17 UTC and 2025-04-09 10:17 UTC may need a replay.

• Subscribe to DatoCMS's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=datocms works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from DatoCMS 1

1. resolvedApr 9, 2025, 10:17 AM UTC

   Resolved — Postmortem: we made some changes in our Cloudflare configuration to enable a higher cache hit ratio. We relied on the fact that Cloudflare explicitly states that they support URLs up to 16KB long: https://developers.cloudflare.com/workers/platform/limits/#request-limits Turns out it's not true: we asked for more info from Cloudflare; in the meantime, we reverted our optimization. Monitoring — Our services experienced increased response times for 12 minutes between 4:25 CEST and 4:37 CEST today. The issue was promptly identified and resolved by our engineering team. Please note that the status page graphs incorrectly show a +50-minute degradation period due to a misconfiguration in our reporting system. This does not reflect the actual duration of the incident. The reporting system has been corrected. All services are now operating normally with regular response times.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.