Is Render Down Right Now? Check if there is a current outage ongoing.

Engineers have been alerted to and are investigating an issue causing performance degradation for some users in Oregon.

This incident has been resolved.

We've implemented a fix and are monitoring.

We are currently investigating this issue.

We are currently investigating this issue.

Between 2025-05-07 and 2025-05-13, services may have experienced an increase in instances being evicted and restarting. This was due to a failure of a routine cleanup task, which failed in a way that did not trigger our monitoring. We have fixed that task as well as improved monitoring and alerting to prevent this from recurring.

Due to an issue with our infrastructure provider, some services may have experienced downtime between 21:58 and 22:04 on 2025-05-04. Builds and deploys may have been impacted during this time.

This incident has been resolved.

Our team has mitigated this issue and is monitoring the situation. The impact time for this incident is 2025-05-09 02:35 to 02:51 UTC. During this time the following will have been impacted: - Dashboard - REST API - Builds - Deployments

We are currently investigating issues accessing the Render dashboard. Our team is investigating. This should only be impacting access to the dashboard. Render services should not be impacted.

We are currently investigating issues accessing the Render dashboard. Our team is investigating. This should only be impacting access to the dashboard. Render services should not be impacted.

This incident has been resolved.

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

We have identified an infrastructure issue that may result in logs being delayed in the Oregon region. We are working on a resolution.

This incident has been resolved.

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

We have identified an infrastructure issue that may result in logs being delayed in the Oregon region. We are working on a resolution.

This incident has been resolved. Impact to any services was mitigated as of 20:36.

We've identified that builds for services other than static sites were also affected. We continue to monitor for any further issues.

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

We are investigating static sites failing to build in the Oregon and Virginia regions.

This incident has been resolved. Impact to any services was mitigated as of 20:36.

We've identified that builds for services other than static sites were also affected. We continue to monitor for any further issues.

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

We are investigating static sites failing to build in the Oregon and Virginia regions.

This incident has been resolved.

We’ve rolled out a mitigation that’s successfully cleared up all the 502s tied to this specific incident. Things are looking stable so far, but we’re still monitoring and working on a more permanent fix.

We’re still working on a fix and starting to see some improvements from the mitigation steps we’ve taken. We're now focusing on putting a more solid, permanent solution in place and will update this status page as soon as we’ve got more to share.

We have identified the issue and are currently working on mitigating and fixing it.

We've spotted that something has gone wrong. We're currently investigating the issue, and will provide an update soon.

We’re still actively looking into it. So far, it seems like this is primarily affecting some newly created services in the Frankfurt region.

Some services — mostly in the Frankfurt region — have been reported to return 502s on certain requests. It’s not hitting all services, and we can’t confirm yet if it’s limited to just one region. We’re on it and investigating.

This incident has been resolved.

We’ve rolled out a mitigation that’s successfully cleared up all the 502s tied to this specific incident. Things are looking stable so far, but we’re still monitoring and working on a more permanent fix.

We’re still working on a fix and starting to see some improvements from the mitigation steps we’ve taken. We're now focusing on putting a more solid, permanent solution in place and will update this status page as soon as we’ve got more to share.

We have identified the issue and are currently working on mitigating and fixing it.

We've spotted that something has gone wrong. We're currently investigating the issue, and will provide an update soon.

We’re still actively looking into it. So far, it seems like this is primarily affecting some newly created services in the Frankfurt region.

Some services — mostly in the Frankfurt region — have been reported to return 502s on certain requests. It’s not hitting all services, and we can’t confirm yet if it’s limited to just one region.We’re on it and investigating.

This incident has been resolved.

This issue has been mitigated.

We are seeing increased rates of 404s for valid URLs on services hosted in Oregon, including Static Sites, we are working on resolving this issue.

This incident has been resolved.

This issue has been mitigated.

We are seeing increased rates of 404s for valid URLs on services hosted in Oregon, including Static Sites, we are working on resolving this issue.

We've seen no further symptoms of network congestion in this region.

Our upstream provider has allocated more network capacity in the congested region.

We've received confirmation from an upstream provider that they have been experiencing networking congestion in this region during these periods of impact. They are now working on a remediation.

Despite increased networking resource allocation, we've see another instance of this issue. We're now collaborating with upstream providers to identify the source of these transient networking errors

We have not seen a reoccurrence of the issue after making changes yesterday afternoon, but are continuing to monitor as the problem seems to be intermittent.

We are continuing to investigate while working on provisioning more networking resources and improving observability into the issue.

We are currently investigating this issue.

We've seen no further symptoms of network congestion in this region.

Our upstream provider has allocated more network capacity in the congested region.

We've received confirmation from an upstream provider that they have been experiencing networking congestion in this region during these periods of impact. They are now working on a remediation.

Despite increased networking resource allocation, we've see another instance of this issue. We're now collaborating with upstream providers to identify the source of these transient networking errors

We have not seen a reoccurrence of the issue after making changes yesterday afternoon, but are continuing to monitor as the problem seems to be intermittent.

We are continuing to investigate while working on provisioning more networking resources and improving observability into the issue.

We are currently investigating this issue.

This incident has been resolved.

Engineers are fixing an issue causing elevated rates of 404s for services in the Ohio and Oregon regions.

This incident has been resolved.

We have implemented a fix and continue to monitor the situation.

We are currently investigating this issue.

This incident has been resolved.

We are currently investigating this issue.

We have resolved the issue and logs are now working for all customers.

We are currently investigating reports of customers unable to view logs in our dashboard. The message displayed will be "Something went wrong while loading your logs. Try searching again. Internal Server Error"

This incident has been resolved.

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

We have made initial improvements but are continuing to work on a complete fix.

The previous mitigation did not fully address the issue, so degraded performance is still being observed. We are working on a fix to fully resolve the issue.

We will continue to monitor builds & deploys in Frankfurt for the next 16-18 hours.

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

We are currently seeing degraded (slow) builds in the Frankfurt region.

This incident has been resolved.

Dashboard is mostly recovered, but Shell access is still impacted. Redis/KeyVal was also impacted, but is now recovered.

Builds and deploys are now fully operational.

We have identified the issue and are working on resolution.

We've identified an issue that caused Dashboard to be non-responsive for ~10 minutes (between 17:19 and 17:30 UTC). A fix has been put in place and we are monitoring results.

This incident has been resolved.

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

Free web services are unavailable for some customers in Frankfurt. We are investigating the issue.

This maintenance has been canceled. We were able to workaround the need for a maintenance period.

We will be upgrading critical infrastructure on March 19th at 4:00 pm PDT (March 19th 11:00 pm UTC). For up to 30 minutes, you will be unable to view, edit, create or deploy services and databases. There will be no interruptions to deployed services and databases. If you need help, please get in touch at support@render.com or talk to us on our community forum, https://community.render.com

This incident has been resolved.

Between approximately 14:00 and 14:40 UTC, builds and deploys may have failed for some services located in the Frankfurt region. Services are no longer affected and engineers are investigating.

This incident has been resolved.

If 2FA is enabled, users may be unable to enter their one-time password. We are investigating.

Between 19:57 and 21:08 UTC, users would have been unable to SSH into hosts. This has now been resolved.

All services have recovered. Resolving.

Render engineers have rolled out the fix and free tier has recovered in all regions except for Frankfurt.

Engineers are rolling rolling out a fix now to free tier in all regions.

We are continuing to investigate this issue.

Render engineers are fixing an issue disrupting Free Tier Services.

This incident has been resolved.

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

We've implemented a mitigation for Builds and Deploys. We are continuing to investigate Free Tier scale-ups.

Builds and deploys are degraded for all services. Free tier services are also impacted when spinning up from idle.

We are currently investigating this issue.

This incident has been resolved.

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.

We are currently investigating this issue.

We have rolled out our mitigation as of 4:25p PST. Resolving.

Engineers have identified a mitigation to prevent this from occurring in the future and we will leave this incident in a state of Monitoring until it has been fully rolled out. This is expected to be complete within a few hours.

We're investigating an increase in errors in our HTTP routing layer from 10:40 to 11:00 PST. The impact is over and we're working on a mitigation.

As of 18:25 Pacific (Jan 31 02:25 GMT), this issue has been resolved.

Logins to dashboard.render.com are currently failing, attempting to do so returns you to the main login page. Engineering has already begun diagnosing the issue.

This incident has been resolved.

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

Some users are reporting an issue logging into the Render Dashboard with their GitHub login credentials.

This incident has been resolved.

Due to an ongoing outage on GitHub, services may fail to build and consequently deploy.

This incident has been resolved.

We've identified and resolved the issue and metrics should be appearing now as expected.

We are investigating an issue with metrics affecting some users in our Oregon region.

This is now resolved.

Deployments are now succeeding. Please manually trigger any stuck builds.

We are continuing to investigate the cause of deployments not succeeding in Frankfurt.

We are continuing to investigate the cause of deployments not succeeding in Frankfurt.

We're investigating reports of deployments in our Frankfurt region not completing and getting stuck at "Build Successful"

# Summary Beginning at 10:03 PST on December 3, 2024, Render's routing service was unable to reach newly deployed user services, resulting in 404 errors for end users. Some routing service instances also restarted automatically, which abruptly terminated HTTP connections and reduced capacity for all web traffic. The root cause was expiring TLS certificates on internal Render components, which created inconsistent internal state for Render's routing service. The affected certificates were refreshed and the routing service was restarted beginning at 10:24 PST and was fully recovered by 10:37 PST. # Impact _Impact 1. Starting at 10:03 PST, many services that deployed in this time period experienced full downtime. Clients to those services received 404 errors with the header no-server._ _Impact 2. Starting at 10:08 PST, the routing service started abruptly terminating connections, but was otherwise able to continue serving traffic normally._ _Recovery. By 10:37 PST, all routing service instances were reconnected to the metadata service and full service was restored._ # Timeline \(PST\) * 10:03 - Certificates in some clusters begin to expire resulting in Impact 1. * 10:08 - Some routing service instances begin to restart resulting in Impact 2. * 10:15 - An internal Render web service becomes unavailable after a deploy and an internal incident is opened. * 10:18 - Render engineers are paged because the routing service has stopped getting updates in some clusters * 10:20 - Render engineers identify routing service is failing to connect to metadata service * 10:24 - Render engineers restart the metadata service to refresh the mTLS certificate, routing service begins to recover * 10:37 - Restarts are completed and routing services in all clusters are recovered # Root Cause  The Render HTTP routing service uses an in-memory metadata cache to route traffic to user services. It relies on the Render metadata service for updates to this cache when changes are made to user services. This incident was triggered when certificates for this metadata service expired. The certificates were previously refreshed on restarts. But, as the metadata service has stabilized, we have been redeploying it less frequently. Although the system is designed to continue serving traffic when the metadata service is unavailable, it failed to account for partial connectivity failure. The certificates expiring caused a partial connectivity failure where updates for newly deployed services were only partially processed, reconciling to an inconsistent state that was unable to route traffic. In an attempt to fail fast, the routing service is designed to crash and restart to resolve any client-side connectivity issues after several minutes of stale data. These restarts did not solve the issue and long-lived connections or in-flight requests to those instances were abruptly terminated. # Mitigations ## Completed * Restart all metadata services to refresh certificates ## Planned * Automatically refresh metadata service TLS certificates. * Update our alert on missing metadata updates to fire sooner. * Add an alert monitoring reachability of the metadata service. * Increase the threshold to tolerate stale metadata before intentionally restarting the HTTP routing service. * Update the routing service metadata cache logic to handle this mixed connectivity state correctly.

This incident has been resolved.

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

We are continuing to investigate this issue.

We are currently investigating this issue.

In order to prevent further failures, engineering has temporarily published Node 18.20.5 using 18.20.4's resources for Render-hosted services. This will be undone as soon as 18.20.5 is normally available. This issue has been resolved.

Node v18.20.5 was released a bit over an hour ago, but its download directories do not contain the necessary data. Services using Node that specify this version, typically by specifying use of the latest release in the v18 series, will fail to deploy, or in the case of Cron Jobs, fail to execute even without a new deployment. Engineering is investigating alternatives to prevent services from failing in this manner.

Cron Job execution logs indicate the environment being set up, but the cron job's command is never executed. Engineering is actively investigating.

Our mitigation is working and the errors have stopped.

We have applied another mitigation and are no longer seeing errors. We will continue monitoring error rates.

The issue has recurred. We are working on implementing a more permanent fix.

We have mitigated the issue and are monitoring failures to ensure it doesn't reoccur.

There is an issue pulling public images from DockerHub. This means that deploying a public DockerHub image that doesn't specify a registry credential may fail. We are working on a fix. In the meantime, specifying your own credentials should avoid the current disruption.

There was a network outage during maintenance on internal networking infrastructure in the Ohio region. The outage was for the time range of 14:55-14:59 PT

Traffic was disrupted for some freetier services in the Oregon region for approximately 8 minutes

Between 12:27 PM and 12:52 PM PDT we saw elevated errors for builds and deploys in Ohio due to an incident with an upstream provider. The upstream incident has been resolved and we are no longer experiencing errors.

We have seen recovery from the upstream provider. We are continuing to monitor builds and deploys in Ohio.

Builds and deploys may be degraded due to an upstream provider outage. We are currently investigating.

This incident has been resolved.

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

We are currently investigating this issue.

There has been no further impact to response times, as previously stated the increased response times occurred from approximately 12:45PM EDT to 13:20PM EDT, and have been stable ever since. This incident has been resolved.

Services hosted in Virginia began encountering increased response times as of approximately 12:45PM (Eastern Daylight Time). While response times seemed to return to normal around 13:20PM, our upstream routing provider has opened a status incident regarding routing performance in a Virginia facility, so this incident remains active as well.

Between 14:15 UTC and 17:52 UTC, some autodeploys and preview deploys were delayed.

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

We are continuing to investigate this issue.

Auto deploys are delayed or not working for some users. We're currently investigating.

Services that used Node but did not specify an explicit version (e.g. a range was used) were unable to deploy due to an issue downloading Node. Issues with Node stemmed from an outage with an upstream provider. The issue has been resolved and services may deploy again.

From 21:26 to 22:09 UTC, there was a configuration issue that prevented the system from processing a subset of logs in Singapore. This resulted in a gap in request logs and network metrics for affected public services. The underlying issue has been resolved.

For around an hour, image-based services in Dashboard were showing up as not existing. These services still existed and remained operational, but could not be accessed in Dashboard during this time. The issue is now resolved.

Engineers were alerted and responded to an issue disrupting all services in our Free Tier in Singapore. Services were disrupted for approximately 12 minutes, from 22:50 UTC to 23:02 UTC

Web services across all regions experienced intermittent request failures from 22:15-22:43 UTC.

Between 1:05 - 1:10 PM PDT the Render Dashboard intermittently failing to load and some Oregon services were affected. Render engineers have identified & fixed the issue.

This incident has been resolved.

We are aware of the issue and are currently investigating.

For 6 minutes, some services were unavailable in the Virginia region. Engineers responded and services were restored at 3:56 PM PDT.

Normal Dashboard and REST API performance has resumed.

A change to the Render API system resulted in slow performance for our Dashboard and REST API. We have reverted this change and are monitoring performance, which appears to have returned to normal. Customer services hosted on Render should not have been affected by this incident unless they are also active users of our REST API.

We are continuing to monitor for any further issues.

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

The Render Dashboard ( https://dashboard.render.com/ ) is encountering performance issues causing slow page loads, or timeouts and failures to load pages. Engineering is actively addressing the issue. Customer services hosted on Render are not affected by this incident.

The incident has been resolved

We have identified the issue and have applied a fix. We are seeing services successfully starting.

We are investigating some services that are not starting in Oregon.

This incident has been resolved.

We've implemented a fix and are continuing to monitor for elevated failure rates.

We've identified the issue and have started work on a mitigation

We're still investigating and looking at ways to best mitigate this

Follow up from https://status.render.com/incidents/jw8wp2ss1566