Managed Infrastructure Monitoring for SMBs
Most small companies have some monitoring: a CloudWatch alarm someone set up years ago, an uptime checker emailing a shared inbox. What they lack is anyone whose job it is to act on it at 3 a.m.
PlatOps sets up monitoring across your servers, cloud accounts, certificates and backups, routes every alert to an engineer by severity, and tunes it every month. It is included in our managed plans, from $3,500 a month.
What we watch for you
Configured in your accounts, in the tools you choose
- Uptime and multi-step synthetic checks
- Server, container and database metrics
- Error-rate alerts from logs
- AWS, Azure and Google Cloud health events
- Certificate, domain and DNS expiry
- Backup success and restore tests
Works with CloudWatch, Azure Monitor, Google Cloud Monitoring, Prometheus, Grafana, Datadog, New Relic and Better Stack.
What we monitor
Six areas cover the outages small companies actually have. Most of them aren't dramatic: a full disk, an expired certificate, a backup that stopped running weeks ago.
Uptime and synthetic checks
Checks from outside your network that behave like a customer: is the site up, does login work, does the API answer within an acceptable time.
- HTTP and API checks from more than one region, so one bad network path doesn't page anyone
- Multi-step checks for the flows that make money: sign-in, checkout, booking
- Response-time thresholds, not just up or down
- A public or private status page if you want one
Infrastructure metrics
Servers, containers, databases and load balancers. We watch the four signals the Google SRE book calls golden: latency, traffic, errors and saturation.
- Disk, memory and connection limits alerted before they run out
- Database replication lag, slow queries and storage growth
- Queue depth and worker backlogs
- Container restarts and failed scheduled jobs
Logs
Most problems announce themselves in logs before anything else. We alert on error-rate changes, not on every single error line.
- Application and web server error rates
- Authentication failures and unusual sign-in patterns
- Retention set to what your compliance scope requires
- Searchable when someone needs to answer “what happened at 2 a.m.?”
Cloud provider alarms and health events
Your provider already knows about some problems before you do. We wire those signals into the same alert route as everything else.
- AWS Health, Azure Service Health and Google Cloud Service Health events for your regions
- Scheduled maintenance and instance retirement notices
- Quota and service-limit warnings
- Billing anomaly alerts, so a runaway resource is caught in days, not at month end
Certificates, domains and DNS
Expired certificates and lapsed domains cause outages that are entirely preventable, and certificate lifetimes are getting shorter.
- TLS certificate expiry on every public hostname, including ones renewed automatically
- Domain registration expiry and auto-renew status
- DNS record changes on your main domains
- Email authentication records (SPF, DKIM, DMARC) still valid after changes
Backups
A backup job that reports success is not the same as a backup you can restore. We check both.
- Alert when a backup job fails or doesn't run at all
- Age of the newest good backup, per system
- Scheduled restore tests with the result recorded
- Backup copies kept in a separate account or region
Why certificates get their own checks: the CA/Browser Forum's Ballot SC-081 cut the maximum lifetime of public TLS certificates to 200 days from March 2026, with further steps to 100 days in 2027 and 47 days in 2029. Let's Encrypt stopped sending expiry reminder emails in June 2025. Renewal has to be automated, and automation has to be watched.
The four golden signals come from the Monitoring Distributed Systems chapter of Google's Site Reliability Engineering book.
Alert routing and on-call
Monitoring is only as good as what happens after an alert fires. Every alert gets a severity, and the severity decides who hears about it and when.
| Severity | Typical example | What happens |
|---|---|---|
| P1 — page now | Customers can't use the product, or data is at risk | Pages the on-call engineer at any hour |
| P2 — same day | Degraded but working: one region slow, a replica down, a backup missed | Ticket plus chat message; worked during response hours |
| P3 — planned | Disk at 70%, certificate due in 30 days, a deprecated runtime | Goes on the maintenance list and the monthly report |
Rules we hold alerts to
- Every page must be actionable. If nobody needs to do anything, it becomes a ticket or a dashboard, not a 3 a.m. phone call.
- Alert on what users feel (errors, slowness, failed checks) first, and on causes like high CPU only when they predict an outage.
- Every alert links to a short runbook: what it means, what to check, who to call if it's in your application code.
- Alerts that fire without action twice in a month get fixed or deleted at the monthly review.
The first two follow the paging guidance in Google's SRE book: page only for conditions that are urgent, actionable and visible to users.
Who answers, by plan
- Essential: 24/7 automated monitoring, P1 response under 1 hour at any time, everything else in business hours (9–6 ET).
- Professional: 24/7/365 human response, P1 under 15 minutes, P2 under 30 minutes.
- Enterprise: P1 under 5 minutes and custom terms.
Want your own developers to stay on the rota? We can page them first and act as the escalation, or the other way round. Compare plans.
SLOs, without the jargon
A service level indicator (SLI) is something you measure the way a customer would notice it: the share of checkout requests that succeed, or the share of page loads under two seconds.
A service level objective (SLO) is the target for that measure over a window, such as 99.9% of checkouts succeeding over 30 days. The gap between the target and 100% is the error budget: the amount of failure you have agreed to live with.
Google's SRE book chapter on SLOs argues against 100% targets, because they slow every change and cost far more than users will ever notice. For most SMBs, one or two SLOs on the services customers touch are enough. We alert when the budget is burning fast, using the approach in the SRE workbook, rather than on every blip.
Running your own SLO program and on-call? SRE & on-call covers that.
What an availability target allows
Downtime per 30-day month, simple arithmetic
| Target | Allowed downtime |
|---|---|
| 99% | about 7.2 hours |
| 99.5% | about 3.6 hours |
| 99.9% | about 43 minutes |
| 99.95% | about 22 minutes |
| 99.99% | about 4.3 minutes |
Each extra nine cuts the allowance by ten. Past 99.9%, a single slow deploy or a provider incident can use the whole month, so pick the target your customers need, not the one that sounds best.
Tooling: three honest options
We work with whichever fits your environment and budget, and with what you already have. Licences are billed to you by the vendor, or passed through at cost.
Your cloud provider's own tools
Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring
Good for: Teams on one cloud who want no extra vendor. Metrics and provider health are already there, and access control follows your existing cloud accounts.
Watch out for: Each is billed by metrics, logs, alarms and dashboards used, which adds up quietly. Weak at watching anything outside that one cloud.
Open-source: Prometheus and Grafana
Self-hosted, or managed versions such as Amazon Managed Service for Prometheus and Grafana Cloud
Good for: Kubernetes-heavy teams and anyone who wants no licence fees or vendor lock-in. Alert rules and dashboards live in Git with the rest of your code.
Watch out for: Someone has to run, upgrade and back up the monitoring itself, and long-term storage needs planning.
Commercial platforms
Datadog, New Relic, Better Stack and similar
Good for: The fastest route to good dashboards, APM and uptime checks in one place, across clouds and on-premises.
Watch out for: Pricing scales with hosts, data volume or users. Without limits on what gets sent, the monitoring bill can grow faster than the infrastructure.
Whichever you choose, on-call paging goes to a phone, not only to email or chat, and a separate external uptime check watches the monitoring itself.
Setup, then ongoing
Setting monitoring up is a project with an end. Keeping it useful is the ongoing part, and it is where most in-house setups decay.
What setup delivers
- An inventory of what runs where, and which of it customers depend on
- Uptime, metric, log, cloud-health, certificate, DNS and backup checks configured, as code where the tool allows
- Severity levels and alert routing agreed with you, wired to phone, Slack or Teams
- A runbook for every paging alert
- One or two plain-language SLOs for your most important service
- A test page, end to end, before handover
What we do every month
- 24/7 automated watching on every plan; who responds, and how fast, depends on the plan
- Alert tuning: noisy alerts fixed or removed, gaps added after every incident
- New checks as you add services, domains and environments
- Certificate, domain and backup restore checks kept current
- A monthly report: incidents, SLO status, alert volume and what we changed
Ongoing monitoring is part of our managed plans rather than a separate product: Essential runs $3,500–$7,500 a month, Professional $8,000–$15,000 a month, and Enterprise is priced to scope. Those plans also cover patching, backups and the rest of managed cloud. If you only want monitoring set up and handed to your own team, we quote it after a free 1-hour call.
What monitoring doesn't cover
Fixing your application code
When an alert points at a bug in your product, we diagnose it, give your developers the evidence and keep the service stable while they fix it.
Security monitoring
Threat detection and response is a separate discipline with different tools. See managed security. Learn more
Deep performance tuning
Tracing slow requests and profiling code is its own project. See performance optimization. Learn more
Where monitoring fits
Monitoring tells you something is wrong. These services cover what comes before and after.
Observability services
The overview: monitoring, logs, tracing and incident response, and how they fit together.
Learn moreIncident management
What happens after the page: incident process, communication and postmortems.
Learn morePerformance optimization
Finding why things are slow with tracing and profiling, then fixing it.
Learn moreManaged cloud
Monitoring as part of running your whole cloud: patching, backups, uptime and response.
Learn moreInfrastructure monitoring FAQ
What does infrastructure monitoring include?
At PlatOps it covers six areas: uptime and synthetic checks from outside your network, infrastructure metrics, log-based alerts, cloud provider health events and alarms, certificate, domain and DNS expiry, and backup success and restore tests. Each alert has a severity, a route to a person, and a runbook.
Who responds when an alert fires at night?
That depends on your plan. On Essential, monitoring is automated around the clock and P1 incidents get a response within an hour at any time; other issues are handled in business hours. Professional adds 24/7/365 human response, with P1 under 15 minutes. Enterprise response times are set by contract.
Do you use our existing monitoring tools?
Yes, if they do the job. Most teams already have CloudWatch, Azure Monitor or Google Cloud Monitoring, and many have Datadog, New Relic, Grafana or an uptime checker. We fill gaps and route everything to one place rather than replacing tools for the sake of it.
Which monitoring tool should a small company choose?
On a single cloud with a modest footprint, start with the provider's own tools plus an external uptime checker. Running Kubernetes, or wanting no licence fees, points to Prometheus and Grafana. If you want the fastest setup across several clouds and can control data volume, a commercial platform is reasonable. The tool matters less than having alerts someone acts on.
What is an SLO, in plain terms?
A service level objective is a target for how reliable one thing should be, measured the way a customer would notice, such as 99.9% of checkout requests succeeding over 30 days. The gap between the target and 100% is your error budget. Google's SRE book argues against 100% targets because they slow change and cost far more than users notice.
How long does a monitoring setup take?
For a typical SMB environment, the setup fits inside our standard four-week onboarding, after which our engineers carry the pager. Larger or multi-cloud estates take longer; we scope it after a free 1-hour call.
Do you monitor backups and SSL certificates?
Yes. We alert when a backup job fails or doesn't run, track the age of the newest good backup, and run scheduled restore tests. Every public hostname's certificate is checked for expiry, including auto-renewed ones, because renewals fail silently.
Find out what you're not watching
On a free 1-hour call we go through what you monitor today, where alerts go, and the gaps: the certificate, backup or disk that would take you down first.