“I only found out the site was down when a customer called”—this is not a joke; at companies without monitoring, it happens routinely. Uptime monitoring is a mechanism that automatically and periodically checks whether a server or website is responding normally, and sends an alert when something is wrong. This article explains the basics of uptime monitoring, the practical work of setting it up, and the limits of free tools.
The difference between uptime monitoring and synthetic monitoring
“Monitoring” is a single word, but what it looks at differs.
| Type | What it watches | Examples of anomalies it can detect |
|---|---|---|
| Uptime monitoring (ping monitoring) | Whether the server responds | Server down, network outage |
| Synthetic monitoring (URL monitoring) | Whether the actual page displays correctly | Web server errors, extreme response delays, missing specific strings |
| Resource monitoring | The internal state of CPU, memory, and disk | Disk exhaustion, early signs of rising load |
The key point is that a server can be alive while the site is dead. Cases where the server itself responds but the web application returns an error are common, and ping-only monitoring misses them. In practice, the basic approach is to build around synthetic monitoring (confirming HTTP access to the actual URL) first.
What you lose by not noticing an outage
- Lost opportunity — The sales and leads lost while a contact form or e-commerce store is down do not come back. Without monitoring, an overnight or weekend outage may go unnoticed until the next business day
- Trust — The very fact that “we noticed only when a client pointed it out” erodes a partner’s confidence. Failures happen, but slow detection is read as a problem with your operation
- Impact on search evaluation — Prolonged or frequent outages mean the search engine keeps failing to crawl the site, and nothing good comes of it
- Clues for root-cause analysis — If you don’t know when the outage started and ended, identifying the cause is harder too. Monitoring records are the starting point of incident response
The practical work | What to decide in your monitoring design
- The URLs to monitor — Not just the top page, but the pages that hurt the business if they stop (contact form, login page, checkout path). Including one page that connects to the database lets you indirectly detect DB failures too
- Monitoring interval — One to five minutes is common. The longer the interval, the later the detection. Use five minutes as a guide for a corporate site, and one minute for e-commerce or business systems
- Detection conditions — Looking beyond just the HTTP status—to a response-time threshold (e.g., over 10 seconds is an anomaly) or the presence of a specific string on the page—raises accuracy. Alerting on “two or three consecutive failures” rather than a single failure reduces false alarms
- Alert destinations and time windows — Email alone won’t reach you in the middle of the night. Combine Slack, Chatwork, and, if needed, phone or SMS alerts, and decide who handles first response
Don’t forget SSL certificate expiry monitoring
Alongside site outages, an expired SSL certificate is one of the most common problems. When it expires, the browser displays a full-page warning and the site becomes effectively unusable. Even with auto-renewal set up, it is not unusual for the renewal process to fail unnoticed and the expiry date to arrive. The standard practice is to add expiry monitoring—alerting “30 days and 7 days before expiry”—as a set with your uptime monitoring.
How far you can get with free tools
Free monitoring services such as UptimeRobot can handle the basics of URL monitoring and alerts. Starting for free is itself a good choice. But there are limits.
- The monitoring interval is capped at something longer (e.g., five-minute intervals on free tiers)
- Alert methods and monitoring items (string checks, SSL expiry, etc.) are sometimes paid features
- It means nothing if there is no one to respond after the alert arrives—this is the biggest limit. Who receives the overnight alert, and who investigates the server, is a matter of operational capacity that a tool cannot solve
When to consider managed monitoring
If any of the following apply, there is value in entrusting monitoring and first response to an outside party.
- A site outage directly hits sales or operations (e-commerce, reservations, business systems)
- There is no one in-house who can receive an alert and investigate the server, or only one such person
- You cannot staff a team to respond to overnight or weekend incidents
Thinking of managed monitoring as “buying the capacity to act after you’ve noticed” rather than “outsourcing tool configuration” makes the cost-effectiveness easier to judge.
Rough costs and operational tips
As a rough sense of cost, the monitoring tool itself runs from free to a few thousand yen a month, and even paid plans often stay within ¥10,000 a month for a few dozen monitored targets. Managed monitoring (including first response to alerts and incident investigation) varies with the targets and response hours, but a common range starts from around a few tens of thousands of yen a month. Judge it against the lost opportunity of a single outage.
On the operational side, keeping these two points in mind prevents monitoring from becoming a hollow formality.
- Don’t leave false alarms alone — When false alarms continue, alerts become a “boy who cried wolf” and you miss the real failure. When a false alarm occurs, adjust the detection conditions (consecutive-failure count, timeout value) each time
- Review uptime monthly — Most monitoring services can produce uptime reports. Looking each month at “was last month 99.9%?” and “are short, intermittent outages increasing?” gives you material for deciding on a server move or upgrade
Summary | Start with a single URL check
Uptime monitoring is a high-return measure: the loss it prevents is large relative to the cost of setting it up. Start with synthetic monitoring of your main pages and SSL expiry monitoring. At SHANNON, we offer a website and server monitoring service and can take on everything from monitoring design to first-line investigation and recovery during an incident, under one roof. We put to work the same setup we use daily to monitor and respond to incidents on our own services, so if you want the response after the alert handled too, please get in touch.