Why we built Serverpacemaker

14 September 2026

We were tired of waking up to a broken website.

Not broken in a dramatic way — not a disk crash or a data loss event. Just broken in the boring way: nginx had stopped, or php-fpm had run out of workers, or redis had crashed silently at 3 AM and the whole site was returning 502s.

The fix was always the same. SSH in. Run systemctl restart nginx. Everything comes back. The site works. Nothing was actually wrong — the service had just stopped.

We knew about systemd's Restart= policy. We'd used it. But it only catches processes that exit. It doesn't catch a service that's running but broken. And most of the time, we didn't configure it at all. We'd set up a service, it worked, and we moved on. When it crashed a month later, we'd fix it manually and forget to add the restart policy. Again.

We looked at Monit. It works, but the config is its own DSL and the status page looks like it was designed in 2005. We looked at supervisord. It needs Python and an INI file and it's really designed to run processes, not monitor systemd services. We looked at the whole category of "monitoring tools" — Zabbix, Nagios, Prometheus, Datadog — and realized they were solving a different problem. They tell you what's wrong. We already knew what was wrong. We just wanted it fixed.

So we built the smallest possible thing.

The pacemaker metaphor

A cardiac pacemaker sits quietly in a patient's chest. It watches one signal — the heartbeat. When the rhythm fails, it emits a pulse. When the rhythm is normal, it does nothing. It doesn't diagnose the cause of the arrhythmia. It doesn't alert the hospital. It doesn't coordinate with other devices. It has no buttons, no screen, no user interface. It just keeps the heart beating.

That's what we wanted for services. Watch a list of them. If one stops, restart it. Log the event. Do nothing else.

No dashboard to configure. No alerts to tune. No integrations to wire up. No config DSL to learn. Just a JSON file with a list of service names, and a binary that runs forever.

What "does one thing" actually means

The temptation with any utility is to keep adding. "While we're here, let's add email alerts." Then "let's add a Slack integration." Then "let's add a web dashboard you can log into from anywhere." Then "let's add multi-server coordination."

Six months later, you've built a monitoring platform. You have a config file with 200 options, a database, a web server you have to secure, and a support burden you didn't sign up for. You've solved a different problem than the one you started with.

Serverpacemaker refuses to grow in that direction. The roadmap is short and it stays short:

Watch services
Restart them if they stop
Log every action
Show current state on a read-only page
Let the operator pause it safely when they need to do maintenance

That's the entire product. Every feature request we get is filtered through one question: would a pacemaker do this?

If the answer is no, the answer is no.

Why we're selling it, not giving it away

We could have made it open source. We thought about it. But there's a specific reason we're selling it: sustainability.

A pacemaker requires trust. It runs as root. It restarts services. It has to be reliable for years without intervention. That means it has to be maintained — for security updates, for new Ubuntu releases, for bugs that emerge in the field.

Open source projects with no revenue model get abandoned. The developer moves on, the project stagnates, and users are left with a tool that no longer works on their system. We didn't want that for Serverpacemaker.

Charging $29 once, per server, lets us keep the tool alive. It also keeps the incentive aligned: we only make money once, so we have no reason to add features you didn't ask for. The binary you buy today is the binary you'll run in five years. Maybe with a security patch, maybe with a new Ubuntu version, but always the same tool.

What we don't do

We don't run sales calls. We don't have a support portal. We don't have a customer success team. We don't do enterprise contracts.

What we do: answer emails. Fix bugs. Ship a binary. Charge a fair price. That's it.

If that sounds like the kind of tool you'd want on your server, take a look. If it doesn't, that's fine — systemd might be enough for you, and that's a valid answer.

But if you've ever woken up to a broken site because a service stopped at 3 AM and nobody noticed until morning, we built this for you.

Serverpacemaker is a pacemaker for services. It watches them. It restarts them if they stop. That's the whole product. Learn more →