If you run your own web app on a small server, you are probably the person who hears about it first when something breaks. A customer emails, a cron job stops quietly, or the site shows an error page after a deploy. This post sets out what to check first, so you hear about problems from your own monitoring before your users do.
Why a self-hosted app needs a check from outside the server, not only from inside it
Most small servers already have some internal checks. A process manager restarts a crashed service. A log file records errors. A script writes disk usage to a file. These help, but they all run on the machine that is having the problem. If the server loses its network connection, runs out of memory, or the reverse proxy stops answering, the internal checks may stop running too, and you hear nothing.
A monitor that runs from outside the server asks the question a visitor would ask: can I reach this address and get a sensible response? If the answer is no, you get an alert, whatever state the server is in. That is the main reason to add an external check before anything else.
The three checks to add first: the public page, the login or health route, and a heartbeat for the nightly job
You do not need a long list to start. Three checks cover most of what a small app needs.
The first is the public page. Pick the address a visitor lands on, usually the home page or the main product page. A monitor that requests this page and checks for a normal response will tell you when the site is down, when the certificate or domain has a problem, or when the server stops answering.
The second is a route that exercises the app itself. This might be the login page, an API status route, or a health route your code provides for this purpose. The public page can load from a cache or a static file while the application behind it has failed. A route that touches the app will show that gap. Keep the route simple and quick to answer, so the check does not add load to the app it is watching.
The third is a heartbeat for the nightly job. A heartbeat monitor works the other way round from a page check. Your job sends a ping to an address when it finishes. If the ping does not arrive within the window you have set, the monitor raises an alert. This is the right tool for backups, database clean-ups, report emails and any cron job that fails silently. A job that never runs produces no error message, so a page check cannot catch it. A heartbeat can.
With these three in place, you cover the site a visitor sees, the app behind it, and the work that happens when nobody is watching.
What to alert on and what to leave as a note, so a slow minute does not wake you
An alert should mean that someone needs to act. If every small change in response time sends a message, people learn to ignore the messages, and then the real alert gets ignored too.
Alert on things that stop the app from working for a visitor. A page that does not load, a route that returns an error status, or a heartbeat that never arrives all fit this description. These need a response, even at an inconvenient hour, so they belong in the alert list.
Leave slow responses as a note. If the home page took two seconds on one check and then loaded normally the next time, that is worth recording so you can see a pattern, but it is not a reason to call someone. Look at the history when you next review the app. Notes of this kind help you spot a slow database query or a growing image file before it becomes a real outage.
A simple rule helps here. Before you add an alert, ask what you would do at two in the morning if it fired. If the answer is nothing, it is a note.
How to choose a check interval for a small app and a small team
The check interval is how often the monitor asks the question. Shorter intervals find problems sooner. They also send more requests to your server and, for heartbeats, expect your jobs to report more often.
For a small app run by one or two people, the right interval is the one that matches how long you can wait to hear about a fault. If a broken checkout page costs you sales every minute, pick a shorter interval for that check. If a nightly backup only needs to be confirmed by the morning, a heartbeat window of a day is enough. Check the monitor settings in the docs for the intervals and windows currently available, and set each check to match the job or page it covers rather than choosing one value for everything.
The same logic applies to a team. A single shared interval is easier to explain, but it may be too slow for the important pages and too fast for the background work. Decide each check's interval when you add it, and write the reason in the monitor's name or notes so the next person understands it.
How to send alerts to the people in your organisation and nobody else
Alerts should go to the people who can act on them, and only to them. Alert emails go only to people in your organisation, so you can add the colleagues who look after the app and leave everyone else out. If you are a solo developer, that may just be you. For a small agency or a product team of up to 10 people, it is usually the two or three people who take turns on call.
Write down who gets which alerts. A page check for a client site might go to the developer who built it. A heartbeat for a backup might go to whoever owns the data. This avoids the situation where every alert lands in one shared inbox and nobody feels responsible for the reply.
Review the list when people join or leave. An alert that still goes to someone who no longer works on the app is a common cause of problems that sit unanswered for days.
A short checklist to finish in one sitting, using the free plan with 10 monitors
You can set up the core checks in one session. The free plan includes 10 monitors, which is enough for the three checks in this post across several apps, with room to spare.
- List your self-hosted apps and pick the public address for each one.
- Add a page check for the public address of each app.
- Pick a route inside each app that runs real code, such as login or a health route, and add a check for it.
- List the nightly jobs and backups that matter, and add a heartbeat monitor for each one. Make your jobs send the ping when they finish.
- Set an interval for each check that matches how quickly you need to know about a fault.
- Mark which problems need an alert and which should only be noted.
- Add the people in your organisation who should receive each alert, and nobody outside it.
- Trigger a test failure on one check, confirm the alert arrives, and then restore the service.
Set your first three monitors on the free plan, which has 10 monitors. Start free at https://app.aperioflow.co.uk/#/signup
Once the first three are running, you will have a clearer picture of how your app behaves on a normal day. That history makes it much easier to decide what to add next.