If a customer tells you about an outage, you have no monitoring. That is not the bad news; the bad news is that nobody usually knows how long it took for that phone call to arrive.
Short answer: what does server monitoring do?
Server monitoring checks the system regularly from outside and inside, and sends an automatic notification to whoever is responsible when defined thresholds are crossed. It has two layers: availability monitoring (is the site up, and how fast) and resource monitoring (CPU, memory, disk, database). Together they let you see a problem before customers notice it. Basic setup takes about an hour for most businesses, largely with free tools.
Six metrics to watch
| Metric | What it tells you | Example threshold |
|---|---|---|
| Availability | Whether the site opens | Two consecutive failed checks |
| Response time | Whether slowdown has begun | Twice the normal figure |
| CPU usage | Approach to the capacity ceiling | Above 80% for 10 minutes |
| Disk usage | The quietest cause of outages | 85% full |
| Certificate validity | Whether renewal was forgotten | 21 days before expiry |
| Error rate | Application-level trouble | Sudden rise in server errors |
The fourth row deserves attention. A full disk is among the most common and most preventable causes of outage. Log files, old backups and cache folders grow unnoticed; when the disk fills, the database can no longer write and the site suddenly stops. A single threshold alert prevents that entire scenario.
Checking the home page is not enough
The common setup pings the home page every minute and treats a response as "the system works". That misses a significant share of real failures, because the home page is often served from cache and can keep opening while everything behind it has stopped.
What needs monitoring is not a page but a workflow:
- A page that touches the database. A product list, search result or session-dependent screen; choose an address that does not come from cache.
- Availability of the payment flow. The step reaching the payment provider must be checked; payments can stop while the home page works.
- Form submission. Verify periodically that contact or quotation forms actually arrive.
- E-mail delivery. Whether critical messages such as order confirmations leave the system is a separate check.
- Scheduled tasks. Cron jobs can stop silently; set up a signal confirming they ran.
Silent failures are the most expensive: the site is up, nobody complains, and no form has been delivered for days.
Setting alert thresholds properly
- Do not alert on a single check. A brief network hiccup produces false alarms; require two or three consecutive failures.
- Separate warnings from critical alerts. Disk at 85% is a warning (handled in working hours); the site being unreachable is an alert (notified immediately).
- Send notifications to a role, not a person. An alert going to one individual reaches nobody while they are away.
- Match channel to severity. Critical alerts by phone or instant message; warnings by e-mail.
- Review alerts regularly. A threshold triggering constantly is wrong; either the threshold or the underlying problem needs fixing.
- Add a silence check. You must know if the monitoring system itself stops; "no alerts" does not mean safe.
Netişlem expert view: monitoring's value lies before the outage, not during it
Monitoring is usually installed so that "we hear about outages". Its real benefit appears in the period before one. Response times creeping up, CPU loading a little more each day, disk usage rising a percent a week — all visible weeks in advance. Learning during an outage is good; never having one is better.
Our second observation is alert fatigue rendering monitoring useless. A team receiving ten notifications a day does not read the eleventh. The most effective approach we see keeps alerts deliberately few: only situations genuinely requiring action should notify. Everything else belongs in a report.
Third, single-point monitoring misleads. Monitoring running on the server itself cannot tell you when the server has failed. An independent external check is not a complement to internal monitoring but a prerequisite.
Setup checklist
- External availability check configured (from a source independent of the server).
- At least one dynamic page monitored besides the home page.
- Critical flows (payment, forms, e-mail) checked separately.
- CPU, memory and disk thresholds defined.
- SSL expiry warning configured — renewal tracking is covered in our inventory article.
- Warnings and alerts separated with defined channels.
- Notifications go to a role, not one individual.
- Scheduled tasks verified as running.
- The monitoring system itself is monitored.
- A short monthly report produced (availability, average response time, incident count).
Frequently asked questions
I use shared hosting — can I still set up monitoring?
Yes. In-server resource monitoring may be limited to what the provider's panel shows, but external availability and response time monitoring can always be configured. Critical-flow checks are entirely on your side too.
How often should checks run?
A one-to-five-minute interval suffices for availability in most businesses. More frequent checks catch outages sooner but raise the chance of false alarms, so pair them with a consecutive-failure requirement.
Will monitoring slow my server?
External checks add negligible load, and in-server agents consume few resources. The only thing to watch is heavy query-based checks running very frequently; keep those light.
What should I do when an outage happens?
First confirm through an external check whether the problem is yours or the site's, then look at recent changes — a significant share of outages follow a recent change. Having the steps written down shortens the process considerably.
What availability rate should I aim for?
Provider commitments usually quote high figures; what matters is that the figure is being measured. Without your own independent measurement you cannot verify whether the commitment was met, nor claim any remedy.
Conclusion
Monitoring is not a technical luxury but the ability to know before your customer does. An hour of setup shortens outages, catches problems before they grow, and makes provider commitments verifiable. Without it, the first warning always comes from a customer.
If you would like help building your monitoring setup, get in touch. You can review our server management, SLA guarantee and corporate hosting solutions.