Uptime monitoring for agencies means checking every client website from outside, every few minutes, so your team hears about an outage before the client does. Set up three to five checks per site (the home page, a page that hits the database, the checkout or contact page, plus the SSL certificate), send alerts to the person who can fix the problem, and use the recorded uptime in your monthly client reports.
Here's how to set that up for five clients or fifty without drowning in alerts.
Why agencies need it
- You find out first. The worst way to learn about an outage is an email from the client that starts with "Is the site down?". With external checks you know within minutes and can answer "we're already on it".
- You have proof. A hosting or care-plan retainer is hard to justify with "nothing went wrong this month". An uptime figure, a list of incidents with their durations and a response-time trend turn invisible work into something a client can read.
- It settles arguments. When a client says the site was down all morning, the check history shows whether it was the site, their office network, or 40 seconds during a deploy. (How to tell if a site is down for everyone or just one person.)
- It catches the predictable outages. An expired SSL certificate on a client site is embarrassing because it was avoidable.
- It's an easy service to add to a retainer. Monitoring costs little per site and clients understand what it does. To put a number on what an outage costs a client, use the formula in the real cost of website downtime.
What to monitor on each client site
| Monitor | Why | Interval |
|---|---|---|
| Home page | The page the client looks at first. Catches DNS, hosting and certificate failures. | 1 to 5 minutes |
A dynamic page: product page, search results or wp-login.php | A cached home page can keep loading while PHP or the database is down. | 1 to 5 minutes |
| Checkout, booking or contact page | Where the client's revenue or leads come from. | 1 minute or faster |
| API or health endpoint, if the site has one | For web apps and headless sites. | 1 minute or faster |
| SSL certificate | An expired certificate blocks the whole site in every browser. | Checked automatically |
| Response time | A page that takes eight seconds is down as far as visitors are concerned. | Recorded on every check |
Be clear with yourself (and the client) about what a URL check proves: the page was served, with the expected status code, in a reasonable time. It doesn't fill in the form or complete a purchase. Upmonora monitors request a URL with GET or HEAD and check the status code and response time. They can't log in or submit a form yet. So monitor the checkout or form page itself, and keep a manual test order after each deploy as a separate job.
In Upmonora the SSL check isn't an extra monitor. It's on by default for every HTTPS monitor and warns you 30, 14, 7 and 1 day before expiry. Domain expiry isn't monitored, so keep client domain renewal dates in your own calendar.
How to organise many client sites
Forty monitors in one list get messy fast. A few habits keep it readable:
- Name every monitor "Client - Page". For example
Acme Dental - HomeandAcme Dental - Booking. Upmonora's monitor list is sorted by name with anything that's down at the top, so each client's monitors sit together. There are no folders or tags, so the name does the grouping, and it also appears in every alert. - Budget monitors per client. Four per site is a sensible average. The table below shows what each plan holds.
- Tier the intervals. Every monitor has its own interval. Put shops and booking sites on the fastest checks your plan allows and brochure sites on 5 minutes.
- Use the same settings everywhere. Keep the failure threshold at 2 consecutive failures, so one dropped request never alerts anyone. (Why one failed check should never wake you up.)
- Schedule maintenance windows. Plugin-update night shouldn't page anyone or dent a client's uptime figure. During a window, checks keep running but no incident is opened and no alert is sent.
- Automate onboarding. On Starter and above, the REST API can create a new client's monitors from a script. See Create monitors from CI.
| Plan | Monitors | Fastest check | Check history | Status pages | Roughly |
|---|---|---|---|---|---|
| Free | 5 | 5 minutes | 7 days | 1 | 1 client, or a trial run |
| Starter | 25 | 1 minute | 90 days | 3 | About 6 client sites |
| Business | 100 | 30 seconds | 365 days | 10 | About 25 client sites |
Above 100 monitors there's an Enterprise plan. Current prices are on the pricing page.
Alert routing: wake the right person
An alert that goes to everyone is owned by no one. For each client, decide who acts on a failure: the developer, the hosting contact or the account manager.
Upmonora sends down, recovery and SSL-expiry alerts by email, Slack and Microsoft Teams on every plan, and as signed webhooks on Starter and above. You can add any number of email addresses. Each extra address has to confirm before it receives anything.
One thing to plan around: alert channels belong to the account, not to a monitor. Every enabled channel receives the alerts for every monitor. In practice, agencies route like this:
- One shared Slack or Teams channel (for example
#client-alerts) that the delivery team watches. The "Client - Page" name in each alert says whose site it is. - One on-call email address that forwards to whoever is on duty this week, so you change the rota in one place.
- A webhook into your own tooling if you need per-client routing. The payload carries the monitor name, URL, error and incident start time, so a small script or automation can notify the developer responsible for that client.
There are no SMS or phone-call alerts yet, so for overnight cover make sure the Slack channel or inbox reaches a phone with notifications switched on. Keep clients off the alert channels: raw alerts cause more worry than they prevent. Clients get the status page instead. More on this in how to set up alerts people actually read, and the full channel list is on the integrations page.
Client-facing status pages and reports
Status pages
A status page gives a client one link that answers "is my site up?" without emailing you. In Upmonora you choose which monitors appear on a page and give it a name, a description and a brand colour. The page shows live status per component, 90-day uptime bars and the incidents of the last 14 days with their start time and duration. It updates on its own as monitors change state.
Two limits to know. Pages live at upmonora.com/status/your-name, because custom domains aren't available yet. And the number of pages depends on the plan (1, 3 or 10), so "one page per client" works for up to ten clients on Business. Past that, offer a status page as part of a higher care-plan tier. A monitor can appear on more than one page, so you can also keep one internal page that lists every client. New to the idea? Read what a status page is.
Reports
The Reports screen covers any date range up to a year. For each monitor it lists the number of checks, uptime calculated two ways (duration-based SLA uptime and check-based uptime), total downtime, the number of incidents, and average, minimum and maximum response time. On Business you can export that table, and the raw check history of a monitor, as CSV.
There's no PDF or white-label client report, so copy the figures into your own monthly template. A useful client report is short:
- Uptime for the month, as a percentage and as minutes of downtime. (Which uptime figure to quote, and the uptime calculator to convert between the two.)
- Each incident: when, how long, the cause and what you did about it.
- Average response time compared with last month.
- The SSL certificate's expiry date.
A short setup checklist
- List every client site and the three to five URLs that matter on each.
- Create the monitors, named "Client - Page", with a failure threshold of 2.
- Set each interval by what an outage costs that client.
- Confirm SSL monitoring is on for every HTTPS monitor.
- Add your alert channels and use Send test on each one.
- Create a status page for each client who should have one and send them the link.
- Schedule maintenance windows for your regular update slots.
- Once a month, open Reports for the client figures, then look at the health leaderboard on the Monitors screen: it lists the lowest health scores first, which are the client sites that need attention.
Try it on one client before rolling it out: the free plan covers 5 monitors with SSL checks and one status page. Or paste a client URL into the free website checker for a quick reading of its status, speed and certificate.
Frequently asked questions
Why do agencies need uptime monitoring?
Because the agency is the first call when a client site breaks. Monitoring means you find out within minutes instead of hearing it from the client, and it gives you uptime figures for monthly reports and to back up a care plan or retainer.
What should I monitor on a client website?
The home page, a page that exercises the application and database (a product page, search results or the login page), the checkout or contact page, the SSL certificate and the response time. Three to five monitors per site cover most cases.
How many monitors does an agency need?
Count about four per client site: ten clients need roughly 40 monitors, 25 clients about 100. Upmonora's Free plan has 5 monitors, Starter 25 and Business 100, with Enterprise above that.
Can I give each client their own status page?
Yes, up to your plan's limit: 1 status page on Upmonora's Free plan, 3 on Starter and 10 on Business. Each page shows the monitors you choose with live status, 90-day uptime bars and recent incidents.