Coolify makes it straightforward to deploy an app to your own server. It does not tell you when that app stops answering. The server can be running fine while the site on it returns errors, or the certificate has expired, or a container has stopped. You need a check that sits outside the server and asks the same question a visitor would.
Self-hosted apps still need an outside check
When you host an app yourself, it is easy to assume that if the server is up, the app is up. Those are different things. The server can answer a ping while the app inside it has crashed. A deploy can fail halfway and leave an old or broken version serving traffic. A database can run out of connections and every request starts timing out.
An outside check fixes this because it runs from a different place and treats your app as a black box. It requests the address, waits for a reply, and checks what came back. If the reply is wrong or missing, it tells you. That is the view your users have, so it is the view you should monitor.
Monitor each app URL from outside your server
Each app on your Coolify server usually has its own public address. Add each one as its own monitor. Do not rely on a single monitor for the server IP, because that tells you very little about the apps running on it.
Point the monitor at a page that matters. For a web app, that is often the front page or the login page, which exercises more of the stack than a bare homepage served from a cache. Some teams add a simple health endpoint that the app returns only when it can reach its database. If you use one, point the monitor at it.
Set the expected response too. A monitor that accepts any reply will report a broken app as healthy if it returns an error page with a 200 status. Decide what a good response looks like and check for it.
Add a second location check to rule out a local network fault
When a check fails, the first question is whether the app is down or the path to it is broken. A single check from a single place cannot answer that. A problem with your provider's routing, a DNS fault in one region, or a bad connection at the place the check runs from can all look the same as an outage.
A second check from a different network helps you tell these apart. If both fail, the app is probably down. If only one fails, the problem is more likely on the path between that location and your server, and you can wait a little before you wake anyone up.
Before you rely on any second-location check, find out where it runs from, how often it runs, and what counts as a failure. A second check is only useful if you know what it is actually testing.
Heartbeats for scheduled jobs on the same server
A Coolify server often runs more than web apps. It may run backups, clean-up scripts, sync jobs and other cron tasks. A failing cron job does not look like downtime. The app still loads, nothing turns red on a status page, and the problem stays hidden until someone needs the backup that was never written.
A heartbeat monitor covers this gap. The job pings the monitor when it finishes. The monitor expects that ping at a set interval, and if the ping does not arrive, it raises an alert. You are watching for the absence of a signal, which is the right thing to watch for a job that should run on a schedule.
Put the ping at the end of the job, after the work has actually succeeded. For a backup, that means after the file is written and, if you check it, after the file has been verified. A ping at the start of the script only proves the script started. Set the expected interval a little longer than the job's normal run time, so a slightly slow night does not produce a false alarm.
A backup heartbeat is the check most people wish they had after the first time a backup silently stopped. It costs a single line in the job script.
What to alert on first
Start small. A long list of alerts gets muted within a week, and a muted alert is no use. Begin with three things.
First, the public address of each app, with the expected response. If an app stops answering, you want to know before a user tells you.
Second, a heartbeat for each backup job. A backup that has quietly stopped is the failure that hurts most when you finally need it.
Third, any other scheduled job that your business depends on, such as an invoice run, a data sync or a report that a client receives every morning.
Add more later, once you know which alerts are useful and which are noise. Alert emails go only to people in your organisation, so decide who should receive them before you add a colleague or a client contact to the list.
AperioFlow runs uptime monitors and heartbeats in one place, alongside a status page and incident updates, so the same tool can tell you when something breaks and tell your customers what is happening. The free plan includes 10 monitors, which is enough to cover a handful of Coolify apps and a few key jobs. Start free at https://app.aperioflow.co.uk/#/signup