If you run a web app or a client site on your own, you are probably the person who hears first when it goes down. Often that message arrives from a customer, a colleague or a client who has already tried twice. Uptime monitoring exists so that you hear first. This guide covers what to check, how often, when to alert, and who should receive the message.
Start with the pages that matter
You do not need to monitor everything. Start with the few pages that, if they break, cost you money or trust.
For most small sites that means three things:
- The home page. If it does not load, visitors assume the whole site is down.
- The sign-in page. If people cannot log in, they cannot use the product, even if everything else works.
- The checkout page or an API health route. Checkout is where money changes hands. A health route is a simple endpoint your app exposes that returns a success response only when the app and its main dependencies are working.
A health route is worth the small effort to build. A plain home page check can return a cached page while the database behind it is down. A health route can check the database connection and return an error if it fails.
Keep the list short. Each extra monitor is one more thing to look at when an alert fires, and a long list makes it harder to see which failure matters most.
Pick a check interval and explain the trade-off
A check interval is how often the monitor visits your page. Shorter intervals find problems sooner. Longer intervals send less traffic to your server and produce fewer false alarms.
The trade-off is simple. A check every minute means a problem is noticed within a minute or so, but it also means more requests, more log noise and more chances for a single slow response to look like an outage. A check every five minutes is quieter and still useful for most small sites, but a short outage can pass between checks without being seen.
For a site that takes payments or serves a client's live business, a shorter interval is usually worth the extra requests. For an internal tool or a brochure site that rarely changes, a longer interval is fine. Choose the interval you can live with, and write it down so that the next person knows why it was set that way.
AperioFlow runs on the same principle. It checks the monitors you set up at the interval you choose, and it does not claim that every outage will be caught. Monitoring reduces the time you spend not knowing. It does not remove the chance of a missed check.
Alert on repeated failures, not a single blip
The fastest way to make people ignore alerts is to send one for every failed check. Networks drop packets. A server can be slow for thirty seconds during a deploy. A single failure is often nothing.
A better rule is to alert when a check fails more than once in a row. Two or three consecutive failures tell you that something is probably wrong, and they are still early enough to act on. This keeps the alerts that do arrive worth reading.
When you set this up, think about what each alert should tell the reader:
- Which monitor failed, by name, so the reader knows which page or route is affected.
- When it started failing, so the reader can match it with a deploy or a change.
- What the last response looked like, whether that was a timeout, a 500 error or a page that loaded but returned the wrong content.
If an alert does not help someone decide what to do next, it is noise. Cut it or rewrite it.
Decide who gets the message and how
An alert is only useful if the right person sees it quickly. For a solo developer that is you. For a freelancer running client sites, it may be you plus the client's contact. For a small team, it should be the people who can act: whoever is on call this week, and a backup.
AperioFlow sends alert emails only to people in your organisation. Clients and outside contacts do not receive them unless you add them to your organisation. That keeps the list of recipients under your control and makes it clear who is responsible for responding.
Agree the rules before something breaks:
- Who receives alerts for each site.
- Who responds first, and what they do if they cannot.
- When to tell customers, and who writes the message.
The last point matters. A status page is useful only if someone updates it. Put the job on a named person's list, not in a shared hope that somebody will do it.
What a free plan with 10 monitors covers
AperioFlow has a free plan that includes 10 monitors. For a solo developer or a freelancer with a handful of client sites, that is often enough to cover the home page, sign-in and checkout or health route for several projects at once.
What the free plan covers today:
- Monitors for your sites and routes, up to 10.
- Alerts that go to people in your organisation.
- A status page you can keep updated for customers.
- The ability to download your data.
AperioFlow is hosted in France and run from the UK. It is a small company with a live product, so the honest summary is that the service works today for the things listed above. It does not promise that every outage will be caught in time, and it does not replace a proper incident process. It gives you a clear view of what is up, what is down and who needs to know.
If you want to see how it fits your own sites, you can start free with 10 monitors at https://app.aperioflow.co.uk/#/signup. Begin with the home page, sign-in and checkout or health route, set an interval you can live with, and alert on repeated failures. That is enough to start hearing about problems before your customers do.