Render uptime monitoring with outside checks and downtime alerts every 30 seconds
Short answer: Render health checks decide whether an instance gets traffic, and Render restarts an instance after 60 seconds of failures. They do not tell you that your public URL returns errors, that your custom domain broke or that a certificate failed to renew. To know within seconds that a Render service stopped serving customers, you need a check that runs from outside Render and pages a person.
Render behavior checked against render.com/docs
alertping ▸ check preview
simulated
▸ type a domain to watch a check and an alert play out
▸ simulation of 3 regions · US East · EU Central · EU East
▸ waiting…▌
queued
probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (US East, EU Central, EU East). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: EU Central.
Simulation, not a measurement of your site: this preview runs entirely in your browser and the latencies are generated from the domain you typed. Real checks on your monitors run from our US East, EU Central and EU East regions.
read this first
A health check that restarts instances is not an uptime monitor
Render documents its health checks clearly. Every few seconds it sends a TCP connection or, for web services, an HTTP GET to a path you set. A check passes on a 2xx or 3xx response within five seconds. On a new deploy, Render holds traffic until the instances pass, and cancels the deploy if they do not within 15 minutes. On a running service, 15 seconds of consecutive failures stops traffic to that instance and 60 seconds triggers a restart.
That is instance management, and it is good at it. It answers whether this container accepts connections. It does not answer whether a customer in Chicago can load your checkout page. A service can pass its health path and still return 500s on every real route, serve a stale build, or sit behind a custom domain whose DNS record was changed last week. Render sends its own notifications about its own events, and none of it visits your public domain from outside.
The free instance type adds a second wrinkle. Render spins down a free web service after 15 minutes without inbound traffic and takes about a minute to start it again. That is fine for a prototype. It is not what you want in front of paying users, which is why teams with customers move to a paid instance and then need to know when it fails.
the honest table
What Render catches and what only an outside check catches
| Failure | Render on its own | AlertPing from outside |
|---|---|---|
| New deploy never passes its health check | Yes, deploy is cancelled and old version keeps serving | Not its job, use Render |
| An instance stops answering its health path | Yes, traffic stops after 15 seconds and a restart follows at 60 | Sees the symptom if users are affected |
| App returns 500s or wrong content on a live route | Only if the health path itself fails | Yes, with response assertions |
| Custom domain DNS breaks or the domain lapses | No | Yes |
| TLS certificate fails to renew on a custom domain | No | Yes, with days of warning |
| Render itself has an incident | Inside the affected system | Yes, from outside |
| Failure confirmed from a second region before paging | No | Yes, three regions |
Keep the Render health check for rollouts and restarts. Add an outside check for the question customers actually care about, which is whether the page loads and the API answers.
the mechanics
Setting up outside monitoring for a Render service
Step one, add the public URL of the service, preferably your custom domain rather than the onrender.com address, so DNS and certificate failures are in scope. Step two, add a route that runs a trivial query against your database and returns a fixed string. Step three, assert on that string and on response time, not only the status code, because a proxy can return 200 for a dead app.
Step four, choose 30-second checks for anything customer-facing, confirmed from a second region before it counts as downtime, so a single network blip does not wake anyone. Step five, route alerts to SMS and Slack. SMS, email, Slack and webhook alerts are included on every AlertPing plan with no credit packs. Nothing is installed in your Render account and no code changes are needed.
For Render cron jobs and background workers with no public URL, use a heartbeat: the job calls a URL when it finishes, and you are alerted when the call does not arrive.
pick one
Which Render teams need this
Startups selling a SaaS product from Render web services, where an hour of downtime is a support queue and a churned trial. Agencies hosting client apps on Render who need to hear about an outage before the client does. Teams running a public API that partners call. Anyone running a paid instance who realized the dashboard only tells them after they open it.
If your Render service is a hobby project on the free instance type, you do not need this. When someone pays you for that URL, an outside check is the cheapest insurance you can add.
straight answer
What AlertPing does not replace on Render
AlertPing does not show CPU, memory or logs from inside your instance, and it does not roll back a bad deploy. Keep Render metrics and logs for diagnosis. We detect and page, and then you open Render to find out why. Pricing is flat from $49 a month, with 30-second checks from $59.
questions people ask
Render uptime monitoring questions
Does Render have uptime monitoring?
Not as an outside check of your public URL. Render runs health checks every few seconds to decide whether an instance receives traffic, and it sends notifications about its own events. Nothing visits your custom domain from another network and alerts you when real requests fail.
What happens when a Render health check fails?
On a running service, Render stops routing traffic to the failing instance after 15 seconds of consecutive failures and restarts it after 60 seconds, notifying you per your settings. On a new deploy, it cancels the rollout after 15 minutes and keeps the old version serving.
How do I get alerted when my Render app goes down?
Point an external monitor at your public domain, add a route that touches your database, assert on a known response string, confirm failures from more than one region and send the alert to SMS or Slack. AlertPing does this every 30 seconds without changes to your Render account.
Does a Render free web service stay online?
No. Render spins a free web service down after 15 minutes without inbound traffic, and starting it again takes about a minute. Paid instances do not spin down for idleness, so customer-facing apps belong on a paid instance with an outside monitor.
Can AlertPing monitor a Render cron job or background worker?
Yes, with a heartbeat. The job requests a URL when it finishes, and AlertPing alerts you if the request does not arrive on schedule. That covers Render services that have no public address for a regular check.
Can AlertPing monitor a custom domain on Render?
Yes, and you should. Monitoring the custom domain covers DNS changes, certificate renewal and the full path a customer takes, which the onrender.com address skips.
Watch your Render app from outside Render
AlertPing checks your custom domains and API routes as often as every 30 seconds, confirms every failure from a second region, warns before your SSL certificate expires, and sends SMS, email, Slack and webhook alerts on every plan. Flat pricing from $49 a month, with 30-second checks from $59.