Built and run by one person.
The boring $5 tool that tells me when a server goes down
Top•TREMOR - Macro Stress Signals•Quants Agent

The boring $5 tool that tells me when a server goes down

Published: July 22, 2026

Related toolsTREMOR - Macro Stress Signals•Quants Agent

You run a couple of backends, a database, a frontend, maybe a small server on Hetzner or some VPS. One of them falls over on a Sunday afternoon. How do you find out? Is it the client calling you? Or you happening to open the site? Or catching it in the server dashboard you keep? That is not monitoring. That's luck.

The piece that is usually missing is a channel that reaches your phone the second something is wrong, through Do Not Disturb if it is serious, without you building an app or paying for a heavy enterprise pager. I did not know a clean answer to this existed until a few weeks ago. It is called Pushover, it has been around since 2012, it costs a one-time $5, and it has quietly become the thing that tells me when a backend dies, a TLS cert is about to expire, or someone logs in from an IP that is not me.

The one-line version

Pushover is a "send a notification to my phone" button that any script or server can press with a single web request. Your code makes the request, a notification shows up on your phone a second later. That is the whole product.

How it actually works

The flow goes one way, your side makes one outbound call to Pushover, you are never waiting for them to reach into your server. Three hops:

  1. Something on your side notices a problem. That something is just code you already control, a cron job that pings your backend every couple of minutes, your app's error handler, a small monitoring script.
  2. That code makes one outbound HTTPS POST to Pushover's API, carrying a title, a message, and a priority.
  3. Pushover's servers get it and push it to the Pushover app on your phone. They own all the hard delivery machinery, the device registry, the Apple and Google push plumbing, the retry logic, the sounds.

So when people say it lives on their server, that is true in the useful sense, all the delivery machinery is theirs and hosted. You never run a notification server, never touch push certificates, never keep a device list. Your only job is the one outbound POST. Picture it as your code, one POST, Pushover's cloud, your phone.

The one-time setup

The setup is about ten minutes, done once.

A representative snippet

Here is the entire integration, in shell:

curl -s -X POST https://api.pushover.net/1/messages.json \
  --data-urlencode "token=YOUR_APP_TOKEN" \
  --data-urlencode "user=YOUR_USER_KEY" \
  --data-urlencode "title=Backend down" \
  --data-urlencode "message=vigil API failed its liveness check" \
  --data-urlencode "priority=1"

Or the same thing from JavaScript, say inside a Cloudflare Worker or a Node service that just caught an error:

await fetch("https://api.pushover.net/1/messages.json", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({
    token: env.PUSHOVER_APP_TOKEN,
    user:  env.PUSHOVER_USER_KEY,
    title: "5xx spike",
    message: "api.tigzig.com returning 500s",
    priority: "1",
  }),
});

That single call is the whole thing. Everything else, which alerts fire, how loud they are, deduplication, recovery, is just your own logic around when to make the call.

The priority dial

The one feature I lean on most is the priority dial, which runs from -2 to 2 and decides how loud each alert is:

You can also set a different sound per alert type, so after a while you know the cert one from the CPU one by ear without looking. I am still on default sounds, that is a knob I have not turned yet.

Where I actually use it

I run more than 50 apps on tigzig.com across two servers, and Pushover is wired across the whole fleet. Here are some of the things it watches, each one a small script that makes that one POST when it detects its thing, grouped by how loud I made each.

Emergency, priority 2, rings until acknowledged, the get-out-of-bed tier:

High, priority 1, buzzes through quiet hours, the look-soon tier:

Quiet, priority -1, the FYI tier:

Normal, priority 0, the all-clear tier:

It also quietly backs the TLS cert expiry warnings (warn under 21 days, critical under 7, because an expired origin cert silently takes a site down) and the public status-page rollup. The value here is that one simple channel, but by picking a priority per event it becomes a proper tiered pager, some events barely make a sound and the serious ones keep ringing until you answer.

The one pattern worth adding on top

A naive setup fires the same alert every time the cron runs, so a three hour outage becomes ninety identical buzzes. I added a small active_alerts table. The first time a problem is seen I insert a row and fire the Pushover, on every run after that the insert is a no-op because a unique key blocks the duplicate, so it stays silent. When the problem clears I delete the row and send one quiet RECOVERED with the outage duration. Net effect, one alert when it breaks, one when it heals, nothing in between. That fire-once-and-recover pattern is the single most useful thing to add on top of raw Pushover, and it is about fifteen lines of glue.

The brain behind it: the monitoring dashboard

A related note, Pushover is only one part of the monitoring story .. it's just the notification arm. The brain behind it is a monitoring dashboard I built for myself and for my clients, the Tigzig Command Center.

There are great off-the-shelf tools for this (Grafana, Prometheus), but I wanted something exactly to how I think. It started last year as a tiny logging service and a single page, and grew over many months into what I run now.

It pulls everything into one view: live edge traffic, CF worker logs, down to the individual IP, which IPs and which /24 subnets are getting blocked, errors as they happen, the kinds of attacks landing through the day, TLS certs about to expire, and a lot more, tab by tab.

The eye-opener from watching at the IP level and raw hit level: the large majority of what hits a public endpoint is bots, scanners, crawlers, AI agents, and outright attackers, not real users. Actual human raw hits, in the territory of 1-3%.

Self-hosting, and the alternatives

A common question is whether you can self-host it. Pushover itself, no, it is a hosted service with its own phone apps and its own connection to Apple and Google's push networks, you cannot run the Pushover server. If self-hosting is a hard requirement the two well known open source options are ntfy (ntfy.sh), which you can self-host and which has its own phone apps, and Gotify, a self-hosted server with its own Android app.

One point worth knowing, and it runs against the obvious instinct. For the specific job of "tell me my server is down", a hosted notifier like Pushover is the safer choice. If you self-host your notifier on the same infrastructure you are monitoring, then when the box or the network dies your notifier dies with it, and the one message you most needed, "I am down", never gets sent. A hosted independent service has no shared fate with your servers, so it can still deliver the bad news while your own stuff is on fire. Self-host the notifier only if you have a compliance reason to keep the message content in house, and even then, run it somewhere independent of the thing it watches.

On credibility, Pushover is a small, long-lived, boring-in-a-good-way company. It turned ten in 2022 and has been going since 2012. One-time purchase, no subscription for basic phone use, and a generous allowance of 10,000 messages a month for free, shared across all the applications on your account. For a solo dev or a small business it is one of those rare tools that is cheap, does one thing, and has not let me down. Bigger teams reach for heavier pager platforms like PagerDuty or Opsgenie, with on-call schedules and escalation policies, Pushover is the right-sized tool below that tier.

I almost built this myself

A bit of story here. I actually started building my own version of this with Claude Code before I looked around. I'd assumed this kind of thing might be enterprise level .. or require configuring some complex platform.

Explored with Claude Code only ... Pushover came top of list and building my own stopped making sense. Top reasons:

Pushover is zero headache.

The idea is this: just because you can build it doesn't mean you should. As a one-man show it's an easy call. For a big team the math might be different.

Send warnings, keep the secrets out

One rule I would keep whatever else you do. Every message passes through Pushover's servers and lands on your phone's lock screen, so the message should say something needs your attention, go look, and it should never carry the sensitive thing itself. No API keys, no passwords, no customer data in the body. My alerts are pointers, "5xx spike on X", "cert expiring", "IP jailed, open the dashboard", and where I want the detail I attach a link to my own authenticated dashboard rather than putting it in the notification. A lost or stolen phone then leaks a doorbell rather than a filing cabinet.

You can just ask your AI to wire it

You do not really need to study any of this. Pushover is standard enough that any current AI coding assistant already knows it cold. Tell your agent to add a Pushover alert when this backend fails its health check and it will drop in the exact POST above, wire it to your env vars, and you are done. I did not have to read a new doc to set mine up, the agent already knew how, the same way it knows how to send an email. If you want to go deeper the official docs are genuinely good and linked below, but the barrier to entry is close to zero.

The bigger capabilities I do not use

For completeness, here is the ceiling. I use the simple ninety percent case, one recipient, the priority dial, a deep link, dedup and recovery. The rest of the surface, in case you need it:

Roughly, I use it as a personal pager. It can also be a team pager, a broadcast channel, a desktop notifier, and a watch-face data feed.

Cost, once more

It is free for a 30 day trial, after which it is not free, a one-time $4.99 per platform covers it with no subscription on top. You get 10,000 free messages a month across your apps, and the company has been going since 2012. For a small builder it is about the best money-to-value ratio in the whole ops toolbox.