The problem with a downed server or a degraded service isn’t just the technical impact. It’s that you usually find out from a client, a third-party alert, or because someone notices the site isn’t loading. By then you’ve already lost response time — and credibility too.
Continuous monitoring reverses that order: the system alerts you before anyone else notices. And when an alert fires, you already have context about what’s happening instead of starting an investigation from scratch.
I handle the deployment, configuration and maintenance of your infrastructure monitoring, adapted to the actual stack you have — not generic black-box solutions. I work with agencies and development teams that need visibility into their clients’ servers, and with companies and e-commerces that can’t afford to be the last to know about a problem.
What’s usually missing
- Only monitors whether the server responds to ping. Pong. But the web server is down, the database isn’t accepting connections and the email queue has been stuck for hours. A green ping is meaningless.
- Alerts that reach nobody. The tool is configured but notifications go to an email nobody checks, or there’s no defined on-call channel for out-of-hours issues.
- No historical metrics. When something fails, there’s no data about what was happening before to understand the cause. Reactive monitoring is useless for diagnosis.
- Availability checks but no service checks. The site returns 200, but checkout isn’t working because a payment service has an error or the object cache is down.
- No capacity alerts. Disk hits 95% or RAM has been at its limit for days before anyone notices — with no room left to manoeuvre.
How I approach it
Useful monitoring has two layers: availability (is the service working?) and performance and resources (is anything approaching its limit?). Both are necessary, and both require thresholds configured for the specific environment — not default values that generate false positives or miss what matters.
The goal is a setup where every alert is precise: when a notification arrives, there’s something to act on. No noise, no alerts that get ignored because they fire too often.
What’s included
Availability monitoring
- Availability checks for key services: web server, database, object cache, task queue, mail services.
- URL and critical endpoint monitoring: not just that the server responds, but that the application returns what it should.
- TLS certificate checks: alert before expiry, not on the day it expires.
- External monitoring (from outside the server’s network) to detect real outages from the user’s perspective.
Resource and performance monitoring
- CPU, memory, disk and network: continuous metrics with history and threshold alerts.
- Web server load (active workers, response times, 5xx error rate).
- Database health: connections, slow queries, size of critical tables.
- Inode and disk space usage, broken down by partition.
- Queues and background jobs (crons, queue workers).
Alerts and notifications
- Notification channels configured to fit your workflow: email, Slack, Telegram and others.
- Differentiated severity levels: early warning vs. active incident.
- Alert escalation if there’s no response within a defined time.
Tools and deployment
- Self-hosted monitoring stack deployment (Prometheus + Grafana, Netdata, Zabbix, Munin and others as appropriate) or integration with SaaS solutions (UptimeRobot, Better Uptime, etc.).
- Status dashboards so your team has visibility without having to ask.
- Documentation of what’s monitored, why, and what to do when each alert fires.