Registered office
20 Wenlock Road
London N1 7GU
Server monitoring should tell you whether a business service is available, healthy, secure and likely to run out of capacity—and it should send each useful alert to somebody who can act. Monitoring only CPU and disk space leaves large gaps around applications, certificates, backups, queues, dependencies and the customer journey.
Reviewed: 9 September 2026
What should server monitoring cover?
| Layer | Examples | Question answered |
|---|---|---|
| Outside-in | DNS, TLS, HTTP, login or transaction probe | Can a user reach and use it? |
| Host | CPU, memory, disk, processes, hardware | Is the machine healthy? |
| Application | Errors, latency, queues, jobs, dependencies | Is the service working correctly? |
| Data | Database health, replication, backup and restore | Is data protected and available? |
| Security | Sign-ins, privilege, changes, agents and exposure | Is suspicious activity visible? |
Start with the service, not the graph
Write down what the server enables: a website, checkout, file service, database, remote desktop environment or internal application. Identify its users, operating hours, dependencies and acceptable interruption. These answers determine what deserves an alert and how quickly somebody should respond.
A green server does not prove a usable service. The operating system may respond while the application returns errors, a certificate has expired or a payment dependency is unavailable.
Monitor availability from more than one viewpoint
Use host-level checks and an external probe where the service is public. An outside-in check can reveal DNS, routing, firewall, TLS and application failures that an agent on the server cannot see. For internal services, monitor from a representative network location and test authentication where it can be done safely.
- Track status code and response body, not only whether a port opens.
- Follow redirects and alert on unexpected destinations.
- Measure response time and failed checks over an agreed window.
- Use maintenance suppression so planned work does not train people to ignore alerts.
Watch resource pressure and capacity trends
Collect CPU utilisation and load, memory and swap pressure, filesystem capacity and inodes, disk latency and throughput, network errors and connection counts. Virtual and physical servers may also need hypervisor, storage-array, temperature, power and hardware-health signals.
Trend the data. A disk at 70% that grows rapidly can be more urgent than one stable at 85%. Forecasting gives time to archive data, change retention or add capacity through a controlled process.
Monitor the services and jobs that make the server useful
Check whether required services are running and whether they can perform their function. Useful examples include web-worker health, database queries, message queue depth, scheduled-job completion, directory authentication, storage mounts and API dependencies.
For a scheduled import or backup, “process exited successfully” may not prove that the expected records or files arrived. Add a business-level check where the outcome matters.
Include application performance and errors
Track request latency, error rate, throughput and saturation at the application layer. Correlate these with releases and infrastructure changes. Centralise useful error events with request or trace identifiers while excluding secrets and unnecessary personal data.
Define normal behaviour by time and workload. A quiet queue at midnight may be normal; the same queue during order fulfilment may indicate that work is not entering the system.
Monitor databases and data movement
Check connectivity, slow or failed queries, connection pools, locks, replication lag, storage growth and integrity signals supported by the database. Monitor extract, import and synchronisation jobs end to end. Protect monitoring credentials with read-only or minimum necessary permissions.
Treat backup monitoring and restore testing separately
Alert on missed, failed or unusually small backup jobs, repository capacity and loss of immutability or replication. Then run scheduled restore tests. Monitoring shows whether the process reported success; a restore proves whether useful data can be recovered.
ACA’s backup storage estimator can help model retention growth, while the recovery plan should define acceptable data loss and recovery time.
Watch certificates, DNS and external dependencies
Alert before TLS certificates expire and validate the certificate served at the real hostname. Monitor important DNS records and delegated zones for unexpected change. Check third-party APIs, identity services, storage and network links that can make the application fail even while the host remains healthy.
Use ACA’s TLS certificate checker for a point-in-time external inspection and the DNS propagation viewer when validating a deliberate DNS change.
Collect security-relevant logs and changes
Monitor authentication failures, unusual privileged access, account and key changes, firewall activity, security-agent health, unexpected listening services and important configuration changes. The NCSC notes that logs should be chosen according to relevant threats and that high-impact management events may justify immediate alerts. Its logging guidance is a useful design reference.
Send important logs to a protected destination with access and retention appropriate to incident investigation. Logging everything without a purpose can increase cost and noise while still missing the event that matters.
Design alerts that lead to action
Every actionable alert needs a severity, owner, coverage window, notification route, acknowledgement expectation and runbook. Use sustained thresholds, rate-of-change or multiple signals to reduce false alarms. Keep informational data on dashboards or reports instead of paging an engineer.
- What user or business impact might this signal indicate?
- What should the first responder check?
- When should it escalate?
- What evidence should be retained?
- How is the alert tested?
Report outcomes, not monitoring volume
A useful service report shows availability against agreed measures, incidents and response, capacity risks, backup and patch exceptions, recurring alerts and open improvements. Thousands of collected metrics are not evidence that risks are being managed.
ACA provides server monitoring and managed server support for UK businesses under an agreed coverage and response model. Estimate the business impact of outages with the downtime cost calculator before setting priorities.
Frequently asked questions
Is uptime monitoring enough?
No. It may prove that one endpoint responded, but not that the application, data, integrations, backup and security controls are healthy.
How often should a server be checked?
Automated checks can run continuously or at short intervals; human review follows the service’s risk and alert design. Restore tests, access reviews and capacity planning usually run on separate schedules.
Should every warning wake an engineer?
No. Page only on conditions that require timely human action. Route trends and low-impact observations into reports or planned work.
