DatoCMS had 11 outages in the last 2 years — averaging 0.5 incidents per month.
There were 11 DatoCMS outages since July 17, 2025. 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.