# Render status

> Is Render down? Live status, uptime history, and per-region response times for Render's platform, measured by our own probes on three continents.

Published: 2026-08-27 | Canonical: https://yoping.me/status/render

## How we check Render

We watch api.render.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host behind the dashboard, the CLI, and any deploy automation, and pin the response an unauthenticated request receives. Individual services answer on their own onrender.com subdomains or custom domains, so probing one would report on that customer's application rather than on Render's platform.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/render. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is Render?

Render runs applications from a repository: web services, static sites,
background workers, cron jobs, and managed Postgres and Redis, with
builds triggered by pushes and TLS handled automatically. It sits in the
same territory as the platform-as-a-service products that came before it,
with a pricing model and a feature set aimed at teams who want to deploy
without operating servers but still expect a real service rather than a
sandbox.

The most useful mental model during an incident is that Render has two
jobs, and they fail separately. One is building and deploying your code.
The other is running what is already deployed and routing traffic to it.
When the first is degraded you cannot ship, and everything currently
running continues to serve as normal. When the second is degraded, users
are affected and nothing in the dashboard will fix it. The instinct to
redeploy is common and, during a routing incident, actively unhelpful,
since it replaces a working instance with one that has to come up in the
middle of the problem.

Most 502 responses from Render are not Render failing. They mean the
platform accepted the request, tried to hand it to your service, and got
nothing back. An application bound to localhost instead of the provided
port produces this reliably, as does a process that crashes shortly after
starting, a start command that exits cleanly, or a service that is simply
still booting after a deploy. Each looks identical from a browser and
each is visible in the first twenty lines of the service log.

Free instances have a behaviour that generates more false alarms than
anything else on the platform. They spin down when idle and start again
on the next request, so the first request after a quiet period takes
several seconds while the rest are fast. On a low-traffic project this
looks exactly like intermittent unavailability, and any uptime monitor
checking infrequently enough will record it as such. It is documented,
intentional, and not an incident.

Managed databases contribute the last predictable failure. Connection
limits are finite, and they are consumed faster than teams expect once
preview environments, background workers, and a web service with several
processes all connect to the same database. The database stays healthy
and starts refusing new connections, which reads as an outage in
application logs and is a capacity setting doing its job.

## Frequently asked questions

### Is Render down right now?

Check the board above; it reflects our own probes against Render's API from all five of our regions, refreshed every couple of minutes. This measures the platform rather than whether your particular service is running.

### My Render service returns 502 but the platform looks healthy. Why?

A 502 from Render usually means the platform is running and your application is not answering. The common causes are a process that crashed on startup, an application bound to localhost rather than to the port Render provides, a start command that exits, or a service still starting after a deploy. The service logs show which, and they are the right first stop.

### Why is my free service slow on the first request?

Because free instances spin down after a period without traffic and have to start again when a request arrives, which makes the first request after an idle period noticeably slow. This is documented behaviour rather than a fault, it will never show on a status page, and it is the single most common thing mistaken for a Render outage on low-traffic projects.

### Does a Render incident affect my running services or only new deploys?

It depends which part is degraded, and the two are worth separating. Build and deploy problems stop you shipping while running services continue to serve traffic normally. Problems in the network or routing layer affect live traffic, and no amount of redeploying helps, because the path between your users and your service is what has failed.

### My Postgres database on Render is refusing connections. Is that an outage?

Check your connection count before assuming so. Render's managed Postgres plans have connection limits, and an application that opens a connection per worker, or a set of preview environments all pointing at the same database, will exhaust them while the database itself stays healthy. Pooling connections is the fix and it is far easier to arrange before the limit is reached.