Major incident

Render: Builds, deploys, and queued deploys are not starting in all regions

Affected: Builds and Deploys, Builds and Deploys, Builds and Deploys, Builds and Deploys, Builds and Deploys

Current status of Render: Operational — live Render status

Timeline

1. Oct 14, 2026, 19:32 UTC
   investigating
   We are currently investigating this issue.
2. Oct 14, 2026, 19:39 UTC
   identified
   The issue has been identified and a fix is being implemented.
3. Oct 14, 2026, 19:45 UTC
   monitoring
   A fix has been implemented and we are monitoring the results.
4. Oct 14, 2026, 19:47 UTC
   monitoring
   We are continuing to monitor for any further issues.
5. Oct 14, 2026, 20:41 UTC
   monitoring
   We are temporarily pausing deploys to free services.
6. Oct 14, 2026, 20:55 UTC
   identified
   The issue has been identified and a fix is being implemented.
7. Oct 14, 2026, 20:57 UTC
   identified
   Builds are failing to start again across all regions, and our team is still working to address the root cause. Deploys for free services remain paused. We'll share another update as soon as we have more information.
8. Oct 14, 2026, 21:43 UTC
   monitoring
   A fix has been implemented, and we are monitoring the results. Deploys and builds for services running on free instances continue to be paused.
9. Oct 14, 2026, 22:18 UTC
   resolved
   This incident has been resolved.
10. Oct 22, 2026, 17:58 UTC
    postmortem
    ### Summary On October 14, 2026, between 12:12 and 15:08 PDT \(19:12 - 22:08 UTC\), builds and deploys across all regions failed to start, stalled, or were significantly delayed during two periods of impact totaling about 2 hours and 20 minutes. The cause was a database schema migration run as part of a planned version upgrade of our internal job scheduler that coordinates builds, deploys, and other critical platform operations. The migration led to high load and a longer-than-expected recovery time of this system’s database. We will change how we perform upgrades and modifications of this system in a highly available fashion in the future so that a similar change cannot cause an outage again. ### Impact There were two periods of impact. During this time, live user services were not affected, but builds and deploys across all regions failed to start, failed to finish, or were significantly delayed. **Period 1: 12:12 - 12:40 PDT \(19:12 - 19:40 UTC\), about 28 minutes** * New builds and deploys did not start. Deploys in progress stalled. * Some requests to create a deploy through the Dashboard, API, and CLI returned errors \(HTTP 500\). **Partial recovery: 12:40 - 13:18 PDT \(19:40 - 20:18 UTC\)** * Builds and deploys ran, but deploys took about 20 seconds to start instead of a few hundred milliseconds. **Period 2: 13:18 - 15:08 PDT \(20:18 - 22:08 UTC\), about 1 hour 50 minutes** * Builds and deploys were delayed, stalled in progress \(including in pre-deploy\), or failed. From 13:51 PDT, almost no new builds were able to start. * Some queued deploys did not start after recovery, and cancelling them through the API had no effect. Users needed to retry these deploys. ### Root Cause Render uses an internal job scheduler system to coordinate builds, deploys, and other critical platform operations. We were rolling out improvements to how it distributes work, and began a planned version upgrade of this system in production after a successful practice run in a test environment. The upgrade included a database schema migration that locked a large table and drove database CPU utilization to 100%. This database stores both the system’s core job state and secondary data used for search and reporting. The system could not read or write job state reliably, so builds and deploys stopped or slowed. Engineers were alerted to the issue quickly and reverted the upgrade. However, three factors extended the impact: * A pre-upgrade step to create a database clone for rollback could not be completed due to an error from the underlying cloud provider, so a fast rollback was not available. * The migration continued to run on the database after the client performing the upgrade was stopped and the upgrade reverted. It was found and terminated at 13:49 PDT, about 1.5 hours after it started. * An attempt to add capacity to the database failed due to an error from the underlying cloud provider. ### Timeline All times are PDT on 2026-10-14 \(UTC-7\). * **12:13** - The upgrade is started, including the database schema migration. Database load rises and builds and deploys stop starting. * **12:24** - Impact to builds and deploys identified. Incident escalated. * **12:33** - Status page incident opened. * **12:34** - Engineers revert the upgrade and stop the client performing the schema migration. * **12:37** - Job scheduler system recovers. Builds and deploys resume, with slower deploy start times. End of Period 1. * **13:17** - Engineers restart one unhealthy instance of the system to rebalance load. Database connections and errors increase across the system. Start of Period 2. * **13:37** - Free-tier deploys paused to reduce load. * **13:49** - Engineers find the schema migration still running on the database and terminate it. * **14:16** - Database restarted. An attempt to add database capacity fails because of an error from the underlying cloud provider. * **14:27** - Remaining components of the system restarted. * **14:30** - Builds

Updates as published by Render (original).