Render Outage History

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

We are seeing image pull failures within the Oregon region. We have identified the problem and are working on a fix.

We've confirmed that our fix has addressed the issue and workloads are now scheduling normally in all regions.

Provisioning is recovering for free and paid services across all regions. Free services have resumed serving traffic. We are continuing to monitor for further issues.

Paid services are continuing to see recovery across builds and deploys. Free services remain disabled and will return errors if loaded in a browser. Singapore and part of Oregon remain impacted.

We are continuing to monitor for any further issues.

We are disabling new free services in Singapore and partially in Oregon.

We're seeing recovery across all regions.

We are continuing to work on a fix for this issue.

We are now seeing the same issue affecting services in Oregon partially. We are investigating to remediate this as quickly as possible.

Services with paid compute should now be operating normally. Please note that free services in this region are still intermittently disabled.

We are continuing to investigate this issue.

We are seeing some recovery following our mitigation efforts, but we are still working to identify the root cause for a long-term resolution.

We have temporarily disabled free services in Singapore. We are continuing to investigate and work to mitigate the issue.

This issue may affect new instances during builds, scaling, and similar operations. You may experience build/deploy failures. We are still investigating.

We believe this incident has been successfully mitigated. If you continue to experience any issues, please contact support@render.com.

We have re-enabled services using the free instance types in the Singapore region and are currently monitoring the impact.

We have disabled services using free instance types in the Singapore region

Builds and deployments in the Singapore region are currently experiencing degraded performance. You may notice longer than usual completion times.

This incident has been resolved.

We are currently investigating this issue.

All affected services have been migrated to new hosts and are running at this time. This incident has been resolved.

Many services have recovered with healthy disks on new hosts, however this issue remains open as some services are still impaired.

Services located in Ohio, both application types (Web Service, Private Service, etc.) and data types (Postgres, Key Value with persistence) are failing due to disk errors. We are working on mitigations.

This incident has been resolved.

Deploy times have decreased and failures have dropped to baseline levels. We are monitoring for other impacts or other issues.

Deploy delays and failures continue to remain elevated. We are continuing to work on this issue.

We have implemented a mitigation and are currently observing positive results. We are continuing to monitor deploy health across the platform.

We are currently investigating this issue.

Latency has returned to expected levels. Affected services were those created between 2026-02-04T16:30Z and 2026-02-04T18:17Z. Services created outside that period were not affected.

We have determined that services are reachable through their onrender.com address. Requests will be successful but may take longer. We are continuing to work on a fix.

The issue has been identified and a fix is being implemented.

We are currently investigating this issue.

This incident has been resolved. Please reach out to support@render.com for any follow-up questions.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating this issue.

This incident has been resolved.

When viewing service events, an error is returned. We are currently investigating the issue.

From 08:47 to 09:11 UTC, all incoming web traffic in every region failed to reach services and returned 500 errors instead. Our dashboard and API were down too. Background workers, private services, and cron jobs were not affected. The upstream provider has recovered now, and we’re no longer seeing any issues on our side.

The upstream provider is recovering, and we’re seeing recovery on our side too.

Access to services is now recovering, and we are continuing to monitor.

We're experiencing issues with an upstream provider.

We're investigating services not being accessible

This incident has been resolved.

A fix has been implemented and we are monitoring the results. Impact resulted in intermittent latency, timeouts, and errors for some services for ~6 minutes (11:46-11:52 PST).

We are currently investigating an issue impacting web service and static site availability.

This incident has been resolved.

The issue has been identified and a fix is being implemented.

We are continuing to investigate this issue.

We are currently investigating this issue.

This incident has been resolved.

The upstream provider has implemented a fix and recovery is ongoing. We are continuing to monitor the situation.

An upstream provider is experiencing an outage. We are monitoring the situation.

We are currently investigating this issue.

We have observed no further impact and the upstream provider has affirmed full resolution.

The upstream provider has resolved the issue. We’re still checking to see if there’s any remaining impact on our side.

The upstream provider is still suffering from the incident, and we are still waiting for further mitigations from them.

We’re aware of a major incident with an upstream provider that’s impacting some services on Render. You might see some 500s until it’s resolved upstream. We’re also investigating on our side.

# Summary As an infrastructure provider, providing a reliable platform that allows our customers to build and scale their applications with confidence is our highest obligation. We invest heavily to ensure our platform is highly reliable and secure, including in our routing layer that handles billions of HTTP requests every day. On November 5, 2025, we inadvertently rolled back a performance improvement that was gated behind a feature flag. This led to disruption in the form of intermittent 404s for some web services and static sites deployed to the Oregon region. We have fully identified the sequence of events that led to this outage and are in the process of taking steps to prevent it from recurring. # Impact There were two periods where some customers hosting web services and static sites in the Oregon region experienced a partial outage with intermittent 404s. The first period occurred between 10:39 AM PST and 11:25 AM PST . At this time, two Render clusters had slightly degraded service. One cluster returned a negligible number of 404 responses, and the other cluster returned 404 responses for approximately 10% of requests. The second period occurred between 11:59 AM PST to 12:34 AM PST and saw more significant service degradation. During this period, about 50% of all requests to services in the affected cluster received a 404 response. All newly created services in these clusters were affected and received 404 responses during the incident. Updates to existing services were also slow to propagate. Free tier services that were recently deployed or waking from sleep were also affected. # Root Cause Render's routing service depends on a metadata service to receive information about the user services it routes traffic to. When the routing service first starts and upon occasional reconnection, it will request and receive a large volume of data from the metadata service. Earlier in 2025, we successfully deployed a memory optimization related to data transfer between the metadata and routing services using a feature flag. In late October, we removed the flag from code and redeployed, but we didn't redeploy the metadata service, which still depended on the flag. On November 5th, we cleaned up unreferenced feature flags from our system. This caused the metadata service to revert to its less efficient data transfer method, leading to memory exhaustion and crashes. Our routing service is designed to handle metadata service outages and continue serving traffic based on its last known state. However, newly created instances that could not load their initial state were incorrectly sent requests, resulting in 404 errors. During the first period of impact, the metadata service was crashing in two of our clusters, and only a small fraction of routing service instances were impacted. During the second period of impact, we saw a large increase in HTTP requests for services in the affected cluster. This triggered scale-ups of the routing service, all of which returned 404 errors. # Mitigations ## Completed * Increased memory available to the metadata service \(this has since been reverted\) * Temporarily re-enabled the feature flag to support more efficient data transfer between the routing and metadata services \(this has since been removed\) * Deployed the metadata service to no longer rely on the feature flag * Enhanced our monitoring of the metadata service to alert us of this particular failure mode ## Planned * Improve our feature flag hygiene practice to prevent the removal of a feature flag while it is still being evaluated * Prevent the routing service from receiving traffic if it never successfully loaded state from the metadata service

This incident has been resolved.

We are continuing to monitor for any further issues.

A fix has been implemented and we are monitoring the results.

We are continuing to work on a fix for this issue.

We have identified continuing issues in Oregon. A fix is being worked on.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating the issue.

This incident has been resolved.

A fix has been rolled out, and a re-deploy should now work as expected. We’re still keeping an eye on how the fix performs though.

We’ve found the root cause and are rolling out a fix.

Some pre-deploys in Singapore are also affected.

We think some pre-deploys are failing in Oregon and Frankfurt. We haven’t found any other affected regions so far, but we’re actively checking.

We are currently investigating this issue.

This incident has been resolved.

All Render services have recovered, our upstream provider is continuing to recover. We are continuing to monitor impact.

Web Services (paid and free) and Static Site request latencies have returned to normal levels. Issues involving PostgreSQL database creation and inability to create backups persist.

The upstream provider has not yet recovered. We are still seeing request latency for Web Services and Static Sites in Virginia, and some users are unable to create new databases or backups.

Requests routed to Web Services have begun experiencing issues.

We’re seeing some issues again with a few components. Database creation might be slow in Virginia or appears stuck during the creation process.

We’re no longer seeing any issues related to Postgres databases from this incident on our platform.

We are continuing to monitor for any further issues.

We’re seeing steady recovery and keeping an eye on all components to make sure everything’s fully caught up. The upstream provider is still going through its own recovery process too.

Several of our tools were also affected during that time, including support tools, so responses may have been delayed or missed between 08:00 and 09:30 UTC. We’re working through the requests as quickly as we can.

We started seeing increased errors in our infrastructure around 08:00 UTC. Parts of our platform were affected by an outage with an upstream provider. We know that new database creation and backup creation were impacted, but we’re still assessing if there’s any broader impact. We’re seeing signs of recovery now, but we’re continuing to monitor.

This incident has now been resolved. A subset of customers in Oregon, but not all, were impacted. Affected customers were unable to create Postgres services or update the instance type of Postgres services between 19:14 and 20:15 UTC.

A fix has been implemented and we are monitoring the results.

We are currently investigating this issue.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are aware of an issue resulting in stuck builds impacting a small minority of users with the "Wait" setting for their Overlapping Deploy Policy.

This incident has been resolved.

The upstream provider has rolled out a fix and are monitoring the issue. We are monitoring our systems as well.

Due to an outage from an upstream provider, users with image-based services are seeing failed deploys with reports of 401 errors.