Render uptime monitoring

Render health-checks each instance and can email or Slack you when a service turns unhealthy, but nothing at Render requests your public URL from outside, so uptime monitoring on Render means an external monitor on a /health route.

What Render gives you

Render does more than most platforms here. Set a health check path and Render calls it on every instance every few seconds, expecting a 2xx or 3xx within 5 seconds. After 15 seconds of failures it stops routing traffic to that instance, and after 60 seconds it restarts it. A deploy only goes live once the new instances pass, or it is cancelled after 15 minutes. Notifications go to email, Slack or both, for failed deploys and for a service becoming unhealthy.

The gap is the outside view. Those checks go to each instance, not through your domain, so a custom domain that stopped resolving or a regional problem in front of the instances can look healthy from where Render is checking. And the alert travels on the same platform it reports on, so a Render incident can delay the message about it.

Render down, or just your app?

Keep two signals. status.render.com lists platform incidents and lets you subscribe by email. Your own monitor says whether your URL answers. If both are red, it is Render and you wait. If only yours is red, it is your code, your database or your config, and you start reading logs.

The blueprint and the route

render.yaml

services:
  - type: web
    name: api
    runtime: node
    plan: free
    buildCommand: npm ci
    startCommand: node server.js
    healthCheckPath: /health

server.js

const express = require('express');
const { Pool } = require('pg');

const pool = new Pool({ connectionString: process.env.DATABASE_URL });
const app = express();

app.get('/health', async (req, res) => {
  res.set('Cache-Control', 'no-store');
  try {
    await pool.query('select 1');
    res.json({ ok: true });
  } catch {
    res.status(503).json({ ok: false, error: 'db' });
  }
});

app.listen(process.env.PORT || 10000);

Render calls this route every few seconds per instance, so it has to stay cheap: one select 1, no table reads, no third-party calls.

Free tier sleep and uptime monitoring

A free web service spins down after 15 minutes without inbound traffic and takes about a minute to come back. Each workspace gets 750 free instance hours a month, and when they run out Render suspends every free web service until the next month. Render also says free instances are not for production and may restart at any time.

A monitor checking every 5 minutes is inbound traffic, so the service never idles. That is 720 hours in a 30-day month and 744 in a 31-day one. One monitored free service fits in 750. Two do not, and running out takes down every free service in the workspace, not just the second. Render's docs neither forbid nor endorse keep-alive pings. Our advice: if a service matters enough to monitor, move it to a paid instance type, which does not spin down. If it is a demo, let it sleep and do not monitor it, since the one-minute wake-up is longer than the 10 seconds Logdash waits. And never point a monitor at /robots.txt: a sleeping service answers that itself without waking.

Three steps to an alert

Add the URL Create a service in Logdash and give its monitor https://yourapp.onrender.com/health, or your custom domain. Five services fit in the free plan.
Pick the interval Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. Anything outside 200 to 399 counts as down.
Break it on purpose Stop the database under the running service rather than shipping a broken deploy, which Render would refuse to put live. The route returns 503, the next check flips the monitor to down, and a Telegram alert lands with the status code and the error.

Logdash vs UptimeRobot for Render

Feature	Logdash	UptimeRobot
Free monitors	Five services, one monitor each	50, commercial use allowed
Free check interval	Every 5 minutes	Every 5 minutes
Monitor types	HTTP checks, push heartbeats on Pro	HTTP, keyword, port, ping, DNS, SSL and more
Fastest paid interval	15 seconds on Pro, $15 a month	60 seconds on Solo, 30 seconds on Team
Alert channels	Telegram and webhook	Email and Discord free, Slack and Telegram on Solo, webhook on Team
App logs and metrics	Eight SDKs into the same service	Not part of the product

When UptimeRobot is the better pick

You run more than five Render services and want them all on a free plan.
You want email alerts, or SMS and voice. Logdash sends Telegram messages and webhooks only.
You need keyword checks that fail a 200 page showing an error, or port and SSL checks. Logdash has none of those.

Is UptimeRobot a good fit for Render?

Yes: 50 free monitors at 5 minutes covers every Render service you have, and the free plan now allows commercial use. Faster checks cost more there: 60 seconds on Solo, 30 seconds on Team, against 15 seconds on Logdash Pro at $15 a month.

How do I tell if Render is down or just my app?

Check status.render.com and your own monitor side by side. Both red means a platform incident. Only your monitor red means your code, your database or your configuration.

Does Render free tier sleep break uptime monitoring?

A 5-minute monitor stops the sleep, because every check is inbound traffic. That keeps one service awake for about 720 to 744 hours a month out of 750 free hours, so a second monitored free service runs the workspace out and suspends all of them.

Is pinging a Render free tier service to stop sleep allowed?

Render's docs neither forbid nor endorse it, and they say free instances are not for production. If a service needs to stay up, a paid instance type is the supported way to stop spin-down.