Is Render Down Today?
Live status check for Render. See if it's operational, experiencing issues, or completely down right now.
OperationalStatus
operational
Response Time
139ms
Last Checked
Just now
Modern cloud for web services and databases.
Official status page: status.render.com
Common Render issues
- →Free tier services slow to spin up
- →Postgres backups failing silently
- →Build cache misses on every deploy
Latest Render problems
From Render's official status feedRender has reported 6 incidents (1 major) on its official status page in the last 30 days. The latest started Oct 24, 2026. Average time to resolve: 1h 48m. Full outage history →
- resolved
Platform emails not being sent
This incident has been resolved.
Oct 24, 2026Details → - resolved
Degraded network performance
This incident has been resolved.
Oct 23, 2026Details → - resolved
Deploying from GitLab may intermittently fail
This incident has been resolved.
Oct 20, 2026Details → - resolved
Dashboard not updating in real time; Some Workflows SDK requests timing out
This incident has been resolved.
Oct 15, 2026Details → - postmortem
Builds, deploys, and queued deploys are not starting in all regions
### 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 and deploys start to recover, with slower than usual build and deploy times as the backlog is processed. * **15:08** - Deploy start times return to normal and database load returns to pre-incident levels. End of Period 2. * **15:11** - Free-tier deploys and spin-ups gradually re-enabled. * **15:18** - Incident resolved. ### Mitigations **Completed during the incident** * Reverted the job scheduler component upgrade and configuration change \(12:34 PDT\). * Paused free-tier deploys and spin-ups to reduce load, then re-enabled them gradually after recovery. * Terminated the schema migration that was still running on the database \(13:49 PDT\). * Restarted the database and the job scheduler system to restore normal operation. * Paused the upgrade in production until the upgrade process is changed. **Ongoing \(started during the incident\)** * This database is being upgraded to support cross-zone High Availability. **Planned** * Implement a new upgrade and deployment practice for this component: we will implement blue-green deploys to avoid upgrading this system under load in the future. * Adjust the underlying storage mechanisms for the job scheduler to be better suited to this workload type, after we have implemented blue-green deploys.
Oct 14, 2026Details →
Related cloud services
See all Cloud services →Add a Render status badge to your site
Show your visitors whether Render is up. The badge updates automatically and links here.
<a href="https://downsignal.app/is-render-down" target="_blank" rel="noopener"><img src="https://downsignal.app/badge/render.svg" alt="Render status by DownSignal" height="20"></a>
[](https://downsignal.app/is-render-down)
Frequently Asked Questions
Is Render down right now?
▾
Check the live status indicator above for the most current information on Render's availability. We monitor the service continuously and update in real time.
Why is Render not working?
▾
Render may be experiencing server issues, scheduled maintenance, or high traffic. Common causes include infrastructure problems, DNS issues, or CDN outages. Check the status above for real-time information.
How can I fix Render problems?
▾
Try clearing your browser cache, restarting your device, checking your internet connection, switching to a different DNS server (like 8.8.8.8 or 1.1.1.1), or using a VPN. If the issue persists, it may be on Render's end.
When will Render be back online?
▾
Most outages resolve within minutes to a few hours. We continuously monitor Render and update the status in real time. Bookmark this page for the fastest updates during outages.
How does DownSignal check if Render is down?
▾
DownSignal sends HTTP requests to Render's servers every 30 seconds and measures the response time. If the server responds normally, it's marked as Operational. Slow responses indicate Degraded performance, and failed requests mean the service is Down.
About Render Status Monitoring
This page provides real-time status monitoring for Render. DownSignal checks Render's availability every 30 seconds by sending HTTP requests to their servers and measuring response times. If Render responds within normal parameters, we report it as Operational. If response times exceed 3 seconds, it's marked as Degraded. If the request fails entirely or times out, the service is reported as Down.
Experiencing issues with Render? You're not alone — use the "Report issue" button above to let other users know. Common fixes include clearing your browser cache, trying a different network, disabling browser extensions, or waiting a few minutes for the service to recover. For persistent outages, check Render's official status page or social media channels for announcements.