Is Render down right now?

While you wait: the Render incident checklist

1. Name the dependency precisely. Render is your software delivery dependency. Identify which of these surfaces is actually in the production path: source access, builds, artifact publication, package resolution and deployments.
2. Confirm the affected path. Use Render's component and incident detail, then run a read-only source or package probe separately from the web UI, then inspect the pipeline stage that first stopped progressing.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against Render or your own services.
4. Use the rehearsed fallback. For this dependency, freeze routine deploys and use a tested break-glass release path only for an incident fix. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green Render status is the start of validation: drain queued builds deliberately and prevent duplicate deployments when runners reconnect.

What breaks when Render has issues

Render sits in the ci/cd & dev platform layer. An incident can affect source access, builds, artifact publication, package resolution and deployments; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”