Managed cloud operations: what '24/7' really covers

"24/7 monitoring" means very different things depending on the provider, and the gap between what's promised and what's actually covered usually only becomes visible during an incident at 3am.

The questions that actually define the scope

When we take over managed operations for a client, or evaluate a client's existing managed services arrangement, we push for specific answers to a handful of questions that "24/7 monitoring" alone doesn't answer: What's the actual alert response SLA — is someone paged within 5 minutes, or does the ticket sit until the next business day review? What's covered by monitoring — just infrastructure uptime, or also application-level errors, slow query performance, and security anomalies? Who has the authority and access to actually remediate an issue at 2am, versus just acknowledging an alert and waiting for business hours?

What comprehensive coverage actually includes

We structure managed operations around four layers: infrastructure monitoring (is the server/container/database up and responding), application performance monitoring (are response times and error rates within normal range, not just "is it technically running"), security monitoring (unusual access patterns, failed authentication spikes, anomalous data access), and cost monitoring (unexpected spend spikes that often indicate a misconfiguration or, occasionally, unauthorized resource usage). A setup that only covers infrastructure uptime will miss an application quietly returning errors to 30% of users while technically staying "up."

The escalation path that matters as much as the monitoring itself

Detecting an issue is only useful if it triggers the right response quickly. We build tiered escalation: automated remediation for known, well-understood issues (auto-restart a crashed service, auto-scale in response to load), immediate human page for anything outside known patterns or above a severity threshold, and a documented runbook for the on-call engineer covering the most likely failure modes so response doesn't depend on that specific person's memory at 3am.

A concrete example of the gap between "monitored" and "actually covered"

A retail client came to us after a checkout system outage that lasted 6 hours overnight, despite having a "24/7 monitored" arrangement with their previous provider. Investigation found the monitoring was infrastructure-only — the servers were technically up and responding to health checks the entire time, but a database connection pool exhaustion was causing the application to return errors to most checkout attempts. Because the health check only verified the server was running, not that checkout actually worked, no alert fired until a support ticket came in from a frustrated customer the next morning.

We rebuilt their monitoring to include synthetic transaction testing — actually simulating a checkout flow every few minutes and alerting on failure, not just checking server uptime — which would have caught this specific failure within minutes rather than hours.

How Ndakum approaches it

Our Cloud Engineering managed operations always include application-level and synthetic monitoring, not just infrastructure uptime — because "the server is on" and "the product works" are different questions.