DatoCMS had 19 outages in the last 2 years — averaging 0.8 incidents per month.
There were 19 DatoCMS outages since October 6, 2024. Each is summarised below — incident details, duration, and resolution information.
Resolved — A node in our production Kubernetes cluster became unresponsive, causing a brief disruption to some services while workloads were automatically rescheduled to healthy nodes. The duration of the disruption was about 8 minutes.
Resolved — Closing this. Monitoring — Starting from 8:15 AM UTC we received alerts about customers not being able to upload new assets in the media area of their project. This issue only affected uploads made from the administrative area. Uploads performed via the JavaScript client were not impacted. The issue was traced to a recent deploy. We identified and reverted the problematic changes at 9:20 AM UTC. The issue has been resolved and asset uploads are functioning normally. We apologize for the inconvenience.
Resolved — Closing the pinned alert on status Monitoring — A bug prevented daily bandwidth and API call metrics from being saved between January 7 and 12. The data was not lost — it has been aggregated into January 13's totals. Daily metrics will be recorded normally starting January 14. We've added regression tests to prevent this from recurring. We apologize for the inconvenience.
Resolved — On December 2 at 13:13 CET, our API was unavailable for 9 minutes during a deployment, causing errors when accessing the CMS interface. What happened During a routine database migration deployment, code that depended on a not-yet-created database table was accidentally included. This caused the API to fail until we identified and rolled back the changes. Prevention We're implementing stricter code review checks to ensure migration-only deployments don't include dependent code, and adding automated tests to catch this type of issue before deployment. We apologise for the disruption and appreciate your patience.
Completed — Monitoring is completed Verifying — Maintenance completed. We are monitoring the system. Scheduled — We are going to run a maintenance on our billing infrastructure starting from 2025-10-14T05:00 UTC. The expected time to finish is 2 hours. During this maintenance window you could not be able to succesfully complete some operations such as: make changes to your plan (buying a plan, upgrading / downgrading a plan, etc.) update your billing profile (address, credit cards, etc.) tranfer a project destroy an account or an organization destroy a project pay overdue amounts Automatic plan adjustments that we apply to your plan, such as adding an extra collaborator, will be executed after the maintenance.
Resolved — Monitoring completed Monitoring — Between 07:18 UTC and 07:28 UTC a faulty deploy caused degraded performance on our infrastructure. Customers might have noticed increased error rates when trying to access the admin interface, CMA (REST API) and CDA (graphql API). We reverted the deploy and we are monitoring the situation
Resolved — On August 4th, 2025, starting from 14:00 UTC, some customers reported issues building their Gatsby projects that use our gatsby-source-datocms plugin due to records being missing from their GraphQL responses, despite being present in the CMS admin area. The issue was related to a recent change in our code that caused pagination issues with the records fetched by our gatsby-source-datocms plugin. This prevented some records from being visible in the Gatsby GraphQL responses. A rollback of that change was deployed on August 5th at 7:15 UTC. A regression test has been added to ensure that this particular issue with pagination won't happen again.
Resolved — The developers traced the issue to an auto-scaling issue in a part of our infrastructure, where a cluster wasn't properly adding more resources as quickly as needed in order to keep up performance under load. We've since tweaked the scaling configuration and it should not happen again. Our apologies for the slowdown! Resolved — Several customers reported intermittent API performance degradation starting from about 1530 UTC (1730 CEST, 8:30am PST) lasting about an hour. Performance appears to be restored now, but we will continue to monitor the situation and investigate the underlying cause. Please email [email protected] if you are still experiencing any performance issues.
Resolved — The incidents should be resolved. Monitoring — On 2025-06-12, both Cloudflare and Google Cloud started having broad outages: https://www.cloudflarestatus.com/incidents/25r9t0vz99rp https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW This is in turn impacting the availability and performance of some of our services, both in the CMS and the API. It doesn't seem like a full outage yet, but general slowdowns so far. These are in turn also affecting our image CDN: https://status.imgix.com/incidents/ww7rgnbpkqg7 And our videos CDN: https://status.mux.com/incidents/8l2vdkxgs0pp This is an evolving situation and we'll post updates as we can. It is extremely uncommon for major different internet providers to have simultaneous broad outages like this... we are not sure what is going on either, but we will try to post any information we get.
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.
Resolved — The issue has been resolved. Investigating — PDFs served from datocms-assets.com are currently showing up as image thumbnails rather than PDF files for Chromium-based browsers (Chrome and Edge). Firefox and Safari are not affected. A current workaround is to append ?skip-default-optimizations to the end of the URL, like: https://www.datocms-assets.com/123456/123456789-your-file.pdf?skip-default-optimizations That should allow the PDF to load normally. We are working on a permanent resolution and will update here as soon as we can.
Completed — All good 🎉 Verifying — Maintenance completed. We are monitoring In progress — Maintenance in progress Scheduled — Maintenance will start in about one hour, like planned Scheduled — We're going to upgrade our databases with a follower changeover strategy. During this period of time the Content Management API, Content Delivery API and projects administrative interface will be completely unavailable. Cached GraphQL requests in our CDN will continue to work. The actual maintenance impact should be contained to 15 minutes starting from 2024-12-15T09:00:00Z (UTC).
Resolved — This issue can be closed now. Monitoring — We noticed that since 10:30 UTC webhooks have been delivered with some excessive delay. The queue of webhooks went back to normal at 13:30 UTC. We have identified a possible cause and we are working on a permanent solution. At the same time we are monitoring the situation.