Uptime monitoring is a service outside your network that requests your site regularly and tells you when it stops answering. It is the difference between finding out from your own alert and finding out from a customer.
Setting one up takes five minutes. Setting one up so it actually helps takes slightly longer.
It has to run somewhere else
The rule that everything else follows from.
Monitoring installed on the server it watches cannot report that the server is down. Neither can an alert emailed to an address hosted on that server, which is the most common way a perfectly configured monitor turns out to be useless.
External service, external alert destination. That is what makes it a monitor instead of a log.
Check a page, not the homepage
A homepage served from cache can return 200 while the database is down and every other page is broken.
Point the monitor at a page that exercises the application: something that queries the database and renders real content. Some sites add a small status endpoint for exactly this. A page that checks the database and returns a known string.
Then have the monitor look for that string rather than only the status code. A site returning 200 with an error message in the body passes a status check and fails a keyword check, and the second one is the truth.
Set the interval sensibly
One minute for anything transactional. A shop, a booking system, anything where five minutes of downtime costs money.
Five minutes for a normal business site. The difference is detection speed, and for most sites the response time is measured in tens of minutes anyway, so a one-minute interval mostly buys extra alerts rather than extra recovery.
Whatever you choose, require two consecutive failures before alerting. A single failed check catches every transient network blip, and a monitor that cries wolf is one you start ignoring, which is worse than not having it.
Monitor more than the website
Three checks worth having beyond HTTP.
Certificate expiry. An expiring certificate is a scheduled outage you can prevent, and most services will warn you weeks ahead. Renewing your certificate goes into acting on it.
Domain expiry. Rarer and far worse. A lapsed domain takes down the site, the mail and the certificate renewal at once.
Mail. A site that is up while mail is broken looks fine and is not, and nobody reports mail they did not receive.
Alerts have to reach a person
Email alone is not enough for anything urgent. An outage at two in the morning sits unread until the morning, by which time the customers found it first.
Use a second channel for real outages. A phone alert or a message to a chat channel someone watches. Keep email for the less urgent things like certificate warnings.
And send alerts to more than one person if more than one person could act. A monitor pointed at one individual is unmonitored whenever that person is on holiday.
Test the alerting, not just the monitoring
The step almost nobody does.
Deliberately trigger a failure, point the monitor at a URL that does not exist, or pause the site briefly, and confirm the alert actually arrives, on the device you expect, within the time you expect.
Monitors that were configured but never verified are common, and the failure is silent by definition. Do this once at setup and once a year afterwards.
Check from more than one place
A single checking location can report an outage that is really a network problem between that location and your server.
Most services check from several regions and only alert when multiple agree. Turn that on if it is optional. It removes a whole category of false alarm.
It also tells you something real: a site reachable from one continent and not another is a routing or DNS problem instead of a down server, and that is a different investigation entirely. What to Do When Your Website Goes Down explains the triage.
Response time is the early warning
Most services record how long each check took, and that graph is more useful than the up/down status.
A site whose response time has been climbing for a fortnight is heading toward an outage. A daily spike at the same hour is a scheduled job competing with visitors. A sawtooth pattern is usually memory filling and something restarting.
Look at the graph monthly rather than only when an alert fires. There is more on what to check on the server when it points somewhere in monitoring your hosting resources.
What it does not do
Worth being clear, because monitoring gets over-trusted.
It tells you the site answered. It does not tell you the checkout works, the mail sent, or the content is correct. A site serving a maintenance page passes an uptime check.
And it does not prevent anything. It shortens the time between a problem starting and you knowing, which is valuable precisely because the rest of your setup (backups, alerts on resources, a tested restore) is what determines how quickly you can act on what it tells you.
A working setup
One check on a page that touches the database, every five minutes, from multiple locations, alerting after two failures to a phone and an email that is not on this server. Certificate and domain expiry monitored separately. Alerting tested at setup.
That is fifteen minutes of work and it is the difference between a controlled response and a customer's phone call.