Skip to main content
Stackbastion

Draft, not yet published

Uptime monitoring for solo founders: what to set up in one afternoon

7 July 2026· 5 min read · by Stackbastion

Right now, the way you find out your app is down is a user emailing to complain, or you happening to open it yourself. That’s not monitoring, that’s luck. You need something that watches the app around the clock and pings your phone the moment it breaks. Here’s how to set that up in an afternoon, for free.

Why this happens

When you build on a platform, uptime is invisible: someone else watches the servers, and you never think about it. Move to your own hosting and that job becomes yours, except nobody tells you, so it silently doesn’t get done.

The failure mode is quiet. Your app goes down at 2am from a crash, a full disk, or an expired certificate. It stays down for six hours because you’re asleep. You wake up to angry emails and a chunk of lost trust, all because nothing was watching. A monitor that texts you turns a six-hour outage into a fifteen-minute one.

How to fix it

We’ll use Uptime Kuma. It’s free, open source, self-hosted, and genuinely nice to use. It checks your endpoints on a schedule and alerts you through Telegram, email, Slack, or a dozen other channels.

Step 1: run Uptime Kuma

Run it on a different server from your app. This matters: if it lives on the same box, a crash that takes down your app takes down the thing meant to warn you about it. A cheap separate VPS, or a free tier somewhere else, is fine.

The quickest way is Docker:

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma-data:/app/data \
  louislam/uptime-kuma:1

Open http://YOUR_MONITOR_IP:3001, create your admin login, and you’re in. Put Caddy in front of it for HTTPS if it’s internet-facing (see our Caddy post).

Step 2: add a real health check to your app

Don’t just monitor your homepage. A homepage can load fine while the database behind it is dead. Add a health endpoint that actually touches the database and returns an error if it can’t:

// app/api/health/route.js  (Next.js example)
import { db } from '@/lib/db';

export async function GET() {
  try {
    await db.query('SELECT 1');       // prove the DB is reachable
    return new Response('ok', { status: 200 });
  } catch {
    return new Response('db down', { status: 503 });
  }
}

Now a monitor hitting /api/health catches database failures, not just “is the web server on.”

Step 3: create the monitor

In Uptime Kuma, click Add New Monitor and set:

  • Monitor Type: HTTP(s)
  • URL: https://yourapp.com/api/health
  • Heartbeat Interval: 60 seconds
  • Retries: 2 (so one blip doesn’t spam you)
  • Accepted Status Codes: 200

Add a second monitor for your homepage too, so you can tell “database down” apart from “whole app down.”

Step 4: wire up phone alerts

An alert you don’t see is useless, so route it to your phone. Telegram is the easiest. Message @BotFather on Telegram, run /newbot, and it hands you a bot token. Then in Uptime Kuma, go to Settings then Notifications, add a Telegram notification, paste the token, and send yourself a test.

Attach that notification to both monitors. Now, within about two minutes of your app going down, your phone buzzes.

Step 5: watch the certificate too

Expired SSL certificates are a classic solo-founder outage. Uptime Kuma checks certificate expiry automatically for HTTPS monitors and can warn you days before it lapses. Turn on the “Certificate Expiry” notification so you get a heads-up at, say, 14 days out, not a dead site on day zero.

Step 6: put up a status page (optional, 5 minutes)

Uptime Kuma can publish a public status page from your monitors. It’s a nice touch that turns “is it just me?” user emails into a link they can check themselves. Create one under Status Pages and add your monitors.

Or, we do it for you

We run monitoring for customers on infrastructure separate from their app, with alerts that reach a named human, not just an automated inbox nobody reads. If you’d rather not babysit a monitor, book a free audit and we’ll show you what we watch.

FAQ

Why not use a hosted monitor instead of self-hosting?

You can, and free tiers of hosted monitors are fine for a start. Self-hosting Uptime Kuma gives you unlimited monitors, tighter check intervals, and no per-monitor bill as you grow. The one rule either way: the monitor must not live on the same server as the app it watches.

How often should it check?

Every 60 seconds is the sweet spot for a small app. Faster than that rarely helps and can look like abuse to your own rate limiter. With 2 retries at 60 seconds, you learn about a real outage in roughly two minutes without getting paged over a single hiccup.

What’s the difference between monitoring the homepage and the health endpoint?

The homepage tells you the web server is answering. The health endpoint tells you the app can actually do its job, including reaching the database. Monitor both, because “site loads but nothing works” is a real and common failure that a homepage check misses entirely.

It alerted me but the app was actually fine. Now what?

That’s a false positive, usually from a network blip or too-tight timeout. Raise retries to 2 or 3 and set a sensible timeout (5 to 10 seconds). If it keeps happening, the check interval or the monitor’s own network may be the culprit, not your app.

Related posts