If you run an app on a server you manage yourself, you are the person who hears about it when the app stops. Nobody else is watching. The server may be running fine while the app behind it has stopped answering, and the first sign of trouble is often a customer email.
This post covers what to check, where the checks should run, and what to alert on. It does not cover how to run or secure the server itself.
Why a self-hosted app needs a monitor that runs outside the server it watches
A check that runs on the same machine as the app can fail with it. If the server loses its network connection, runs out of disk, or the reverse proxy stops, a check running locally may never send you a message. You need something that sits somewhere else and asks the question a visitor would ask: does the public address respond?
AperioFlow runs its checks from outside your server, so a failure on the box itself shows up as a failed check. That is the point of an outside monitor. It sees what your users see, and it tells you when that changes.
You do not need to know how the app is deployed to set this up. You need the public address, and you need to decide who gets told when it fails.
The first monitor: an HTTPS check on the public address of the app, with a failure threshold of two or three checks in a row
Start with one HTTPS monitor on the public address of the app. Use the address people type into a browser, including the full path if the app lives under one. Do not point it at an internal address or a port that only your proxy can reach, because then you are testing something your visitors never touch.
Each monitor has a failure threshold that you set. It alerts only after that many failed checks in a row. A threshold of one will page you for a single dropped request, which gets noisy fast. A threshold of two or three is a sensible start for most web apps. It means a brief blip passes without a message, but a real outage still reaches you within a few checks.
When you first set this up, watch the monitor for a day. If it alerts on something you would have ignored, raise the threshold. If it takes too long to tell you about a real outage, lower it. Adjust once, then leave it alone unless the app changes.
The certificate check that comes with every HTTPS monitor, with alerts at 30, 14 and 7 days left
An HTTPS monitor also checks the site's certificate. You do not set up a separate monitor for it. The check runs as part of the HTTPS monitor you have just created, and it warns you before the certificate expires.
Alerts go out at 30, 14 and 7 days before expiry. The 30-day warning gives you time to renew at a normal pace. The 14-day warning is for the case where the first one was missed. The 7-day warning is the last chance to fix it before visitors start seeing browser errors.
Expired certificates are one of the most avoidable outages on a self-hosted app, because nothing in the app itself tells you it is about to happen. An outside check catches it, provided the alerts reach someone who can act on them. That is why the next section matters.
A heartbeat monitor for the nightly backup or scheduled task: the job checks in each time it succeeds, and you get an alert when a check-in is late
An HTTPS check tells you whether the app answers. It does not tell you whether your nightly backup ran. For that, use a heartbeat monitor.
A heartbeat works the other way round. The job sends a check-in each time it succeeds. If the check-in does not arrive when expected, you get an alert. The monitor does not need to know what the job does. It only needs to know that the job finished.
This suits cron jobs and backups well. Add a single request at the end of the script that calls the heartbeat address after the backup completes. If the backup fails partway, the request is never sent, and the late check-in raises the alert. Silence becomes the signal.
Set the expected interval to match the schedule, with some margin. A nightly backup that usually finishes by 03:00 should not alert at 03:05 because it took a few extra minutes once. Give it enough room that a normal slow night does not wake anyone.
Where the alerts go: email, web push and webhooks
Alerts can go by email, web push and webhooks. Email is the simplest to start with, and it works for most solo developers. Web push suits you if you want a message in the browser when you are at your desk. Webhooks let you send the alert into your own tools, if you have a place for that.
Alert emails go only to people in your organisation. Choose the people who can act on the alert, not everyone who might like to know. If you are a freelancer, that is probably you. If you run a small agency, pick one or two people who are on call for client sites, and make sure at least one of them has the access to restart the app or renew the certificate.
Keep the routes simple. One clear channel that reaches the right person is better than four channels that everyone ignores.
A short list to copy: what to set up in the first ten minutes
If you want a starting point, work through this list once and leave it.
- Add an HTTPS monitor on the public address of the app, including any path people use.
- Set the failure threshold to two or three checks in a row.
- Confirm the certificate warnings are on. They arrive at 30, 14 and 7 days before expiry as part of the HTTPS monitor.
- Add a heartbeat monitor for the nightly backup or scheduled task, and set the expected interval with some margin.
- Add the heartbeat request to the end of the script, after the job succeeds.
- Choose the alert route, email, web push or webhook, and check the right person receives a test.
- Write down who is on call for the app and where the alert goes if they do not reply.
The free plan includes 10 monitors, so you can cover a few apps and their backups without paying anything. Start free at https://app.aperioflow.co.uk/#/signup and put the first monitor on the app you host yourself.
What this does not cover: how to run or secure the server itself
This post is about watching the app from outside. It does not tell you how to install, update, back up or secure the server, and it does not make any claim that a monitor will stop an outage or a breach. A monitor tells you something has changed. It does not fix it.
You still need to keep the server patched, the backups tested by restoring them, and the access controlled. Those are separate jobs. What a monitor gives you is an earlier message, so you hear about a broken app or a missed backup before a customer does.
You can download your data from AperioFlow at any time, so if you decide to change how you watch your apps later, your monitor history is not locked in.