Uptime monitoring with Better Stack

You have Sentry for errors in your app's code. That tells you when something inside the app crashed. It does not tell you:

• Your server is down (no app to crash).
• Your DNS is misconfigured (no requests reaching the app).
• Your TLS cert expired (browser refusing to connect).
• Your CDN provider is having an outage.
• Your hosting account got suspended.

All these need external monitoring — something polling your site from outside, telling you when it can't reach you. Cheap insurance.

• Pick Better Stack when — you want one product that does monitoring + on-call scheduling + status page + log management. Modern UI; generous free tier.
• Pick UptimeRobot ↗ for the cheapest credible option (free tier with 50 monitors).
• Pick Pingdom ↗ for the most established / enterprise-trusted brand.
• Pick Datadog Synthetics ↗ if you're already on Datadog for app monitoring.
• Pick a status page service (Statuspage ↗, Instatus ↗) for customer-facing communication only.

Better Stack covers most of those in one tool. Useful when you're not yet at the scale that justifies separate vendors for each thing.

Sign up at betterstack.com ↗. Free tier: 10 monitors at 3-minute check intervals, 30 SMS credits/month, 1 status page, 1 GB of logs.

If you only need uptime monitoring, pick the Uptime product. Better Stack also sells Logs (log management) and Telemetry (APM) as separate products you can ignore initially.

Dashboard → Monitors → Create monitor. Configure:

• URL — what to check. Use your real production URL.
• Check frequency — every 30 seconds (paid) / 3 minutes (free). Faster check = faster paging.
• HTTP method — GET by default. For health endpoints, POST or HEAD also work.
• Regions — Better Stack checks from multiple geographic locations and only alerts if multiple regions agree the site is down. Avoids false positives from a single bad checker.
• Expected status code — usually 200. If your health endpoint returns 204, set it accordingly.
• Expected response body (optional) — for content checks. "If the response doesn't contain 'OK', alert."
• SSL/TLS check — alert when cert is within N days of expiring. Default 14 days. Always enable this.

Save. Better Stack starts checking immediately.

Better Stack works fine checking your homepage, but a dedicated health endpoint is better. It lets you verify your app + critical dependencies are working, not just that some page returns HTML.

// Node + Express
app.get("/api/health", async (req, res) => {
  try {
    // Check DB
    await db.raw("SELECT 1");
    // Check Redis / queue / etc.
    // await redis.ping();
    res.status(200).json({ status: "ok" });
  } catch (err) {
    res.status(503).json({ status: "degraded", error: err.message });
  }
});

Point Better Stack at https://yourdomain.com/api/health. Now you alert when your app or its dependencies are broken, not just when the front-end won't load.

By default, Better Stack emails you on incident. For a real on-call setup, add channels:

Dashboard → On-call → Integrations. Connect:

• Slack / Microsoft Teams — bot posts in a channel when incidents fire.
• Phone call — Better Stack calls you. (Uses SMS credits.)
• SMS — text message.
• Push notifications via the Better Stack mobile app.
• PagerDuty / Opsgenie — if you already use those for orchestration.
• Discord — webhook integration.
• Webhook — for anything custom.

For a side project, push notification + Slack is enough. For production with real customers, add SMS or phone as the escalation step.

If you're not paged immediately or you don't acknowledge, what happens next?

Dashboard → On-call → Escalation policies. Define a chain:

1. Immediately — push + Slack.
2. After 5 min if not acknowledged — SMS.
3. After 10 min — phone call.
4. After 15 min — escalate to teammate.

You don't need this on day 1. Add as your business gets bigger and downtime becomes more expensive.

When an incident fires, you get notifications via every channel you set up. Open Better Stack → click Acknowledge. This stops further pages, signals you're investigating.

When the site is back: Better Stack auto-detects recovery on the next successful check and marks the incident as resolved. Optional post-mortem note can be added in the incident detail page.

Average time to detect is ~3 minutes on free tier (check interval). On paid tier with 30-second intervals, ~30 seconds.

Customer-facing communication during incidents matters. Better Stack ships a free status page that auto-updates from your monitors.

Dashboard → Status pages → Create status page:

• Pick which monitors to display publicly. Hide internal ones.
• Group monitors by service ("API", "Web", "CDN").
• Custom domain: status.yourdomain.com via CNAME at your DNS provider.
• Customize colors, logo, page header text.
• Subscriptions: visitors can subscribe to email / SMS / RSS updates.

Manually post incident updates ("we're seeing issues with checkout; investigating") and they appear on the status page + go out to subscribers.

"Did my nightly backup script run?" Uptime monitors check incoming HTTP; heartbeats check the absence of outgoing pings.

Dashboard → Heartbeats → Create heartbeat. Configure the expected interval (e.g., every 24h ± 1h). Better Stack gives you a unique URL.

In your cron / script, ping the URL on every successful run:

#!/usr/bin/env bash
./run-backup.sh && curl -s https://uptime.betterstack.com/api/v1/heartbeat/xxxxxxxx

If Better Stack doesn't see a ping within the expected interval, it fires an incident. Perfect for catching silently-broken scheduled jobs.

For APIs, "did it return 200" isn't enough. You also want to check the response shape didn't break.

Better Stack monitor settings → Advanced → Expected response body. Provide a string to match, or a regex. Example:

Expected response body: "\"status\":\"ok\""

Or use the JSON body check: assert that $.user.id exists, $.health equals "ok", etc. Fires an incident if the schema breaks even though the status code is 200.

• Alerts during deploys — your site is briefly down during a deploy. Solutions: (1) hook your deploy script to pause Better Stack monitoring during the deploy via API, or (2) deploy with zero-downtime strategies so it stays up.
• Cron pinging the heartbeat even on failure — make sure your script only pings on success (use &&, not ;). Otherwise the heartbeat fires "alive" when the backup actually failed.
• Alert fatigue — if you have 20 monitors and 5 are flapping (failing intermittently), real incidents get ignored. Fix flapping monitors (tune the check, the threshold, or the underlying issue) or you'll learn to ignore alerts.
• False positives from a single region — Better Stack defaults to "alert when 2+ regions agree it's down" but this can be tuned. If one region keeps falsely reporting downtime, remove that region from the monitor.

Free: 10 monitors, 3-min interval, 30 SMS credits/month, status page. Team: $25/mo — 50 monitors, 30-sec interval, 100 SMS. Pro: $80/mo — more of everything. Better Stack pricing ↗.

The free tier handles most indie projects. Upgrade when you hit incident volumes that justify it.