Set up uptime monitoring

Three flavors; pick at least one

You can monitor your homepage URL directly — and for static sites, that's fine. For an app with a database and backing services, the homepage might return 200 even when the database is unreachable (cached HTML, static fallback, generic error page). A purpose-built /health endpoint distinguishes three levels:

• Liveness — "the process is running and responding." A one-line endpoint: app.get('/health', (req, res) => res.send('ok')). Good for catching crashed processes; useless for catching dependency failures.
• Readiness — "the process is running and can talk to its dependencies." Check that Postgres responds; check that Redis responds; check that any required external service is reachable. Return 200 only if all checks pass; 503 with details otherwise.
• Deep health — same as readiness but with more checks (queue lengths, recent error rates, etc.). Useful for status pages and dashboards; usually too slow for per-minute uptime pings.

For uptime monitoring, readiness is the right shape:

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1');
    await redis.ping();
    res.json({ status: 'ok', db: 'ok', redis: 'ok' });
  } catch (err) {
    res.status(503).json({ status: 'degraded', error: err.message });
  }
});

Now a 200 from /health means "process up and dependencies reachable" — a much stronger signal than monitoring the homepage.

Free tier handles most personal needs

Sign up at uptimerobot.com. The free tier includes 50 monitors at 5-minute intervals. (The paid Solo tier adds 1-minute intervals and SMS for $7/month.)

Dashboard → + New Monitor:

• Monitor Type: HTTP(s).
• Friendly Name: "Mybrand API" or similar — appears in alerts.
• URL: https://mybrand.com/health.
• Monitoring Interval: 5 minutes (free) or 1 minute (paid).
• Monitor Timeout: 30 seconds. Slower responses count as down.
• Advanced → Keyword Monitoring: optional but useful. Set keyword "ok" with type "Yes — alert when keyword does not exist." Now the monitor checks for the literal string in the response body, not just the HTTP status. Pages that return 200 with an error message stop fooling it.

Save. The monitor starts pinging within a minute; you'll see the response time graph populate.

Email is the default; Slack / Discord wakes the right person

UptimeRobot dashboard → My Settings → Alert Contacts → Add Alert Contact. Each "contact" is a destination for alerts:

• Email — set up by default to the signup email. Free.
• Slack — pick Slack as the type, paste an incoming webhook URL. In Slack: an admin creates the webhook at <workspace>.slack.com/apps → search "Incoming Webhooks" → pick the channel → copy URL. Alerts post into the channel with the monitor name and downtime duration.
• Discord — same pattern. Discord webhook URL from a channel's Integrations settings.
• SMS — paid plans only. Useful for "wake me at 3 AM if production goes down."
• Webhook — for piping into your own systems (PagerDuty, Opsgenie, custom). UptimeRobot POSTs a JSON payload when status changes.

After adding contacts, edit the monitor and tick which contacts should receive its alerts. Production monitors usually get all of email + Slack + SMS; staging monitors get only email.

The settings that make alerts mean something

An uptime monitor that alerts on every flicker becomes background noise. Three settings tame it:

• Grace period (consecutive failures): alert only after the URL has been down for N consecutive checks. Default 1 is too aggressive — set to 2 or 3. A single transient blip stops paging you; a real outage still alerts within 10–15 minutes.
• Multi-region confirmation: in UptimeRobot Pro and competitors, only alert if multiple monitoring regions agree the site is down. Cuts false alerts from a single-region network problem.
• Maintenance windows: schedule scheduled downtime (deploy windows, planned maintenance) so the monitor doesn't alert during them. UptimeRobot: monitor → Maintenance Window → recurring or one-off.

The goal is "every alert is real, every real outage alerts." Drift in either direction kills the value of the monitor.

Public-facing visibility into uptime

A status page (status.mybrand.com) shows your users which parts of your service are up. When something breaks, users check it instead of emailing support. When things are fine, the page is a trust signal.

• UptimeRobot's built-in public status pages — free, attached to your monitors. Dashboard → Status Pages → Create. Custom URL on a UptimeRobot subdomain; custom domain on paid plans. Three minutes to set up.
• Better Stack / Better Uptime — competing service with richer status pages (incident history, scheduled maintenance posts, subscriber notifications). Paid only but cheap; worth it if you have customers.
• Atlassian Statuspage — the enterprise standard. Expensive ($29+/mo) and overbuilt for small projects.
• Self-hosted with Cachet or Upptime — open-source status pages. Free but operational overhead.

For most projects with under 10K users, the free UptimeRobot status page is enough. Upgrade only when you have customers asking for an incident history.

Cron jobs that silently stopped running

HTTP uptime monitors only catch HTTP-facing failures. The other common silent failure: a cron job (nightly backup, weekly digest email, hourly cleanup) that's been broken for two weeks and nobody noticed.

The pattern: a service like Healthchecks.io (free for up to 20 checks) gives you a unique URL per cron job. The job pings the URL on every successful run. If pings stop arriving on the expected schedule, Healthchecks alerts you.

# In your cron job script, last line:
curl -fsS --retry 3 https://hc-ping.com/<your-unique-uuid> > /dev/null

# In crontab:
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://hc-ping.com/<uuid>

Healthchecks knows the schedule (you configure it) and pages you when a ping is overdue. Most useful for backups (where "did the backup run" is the question that only matters the day you need to restore).