Find the gaps in your AWS monitoring before an outage does
Most AWS accounts have resources with no alarms on them at all. We audit what is and is not covered, deploy the alarms as code and run the endpoint checks AWS does not.
Alarm coverage you can prove, not assume
You cannot alarm on what you forgot you were running. Most teams cover the obvious resources and miss the rest, so the first an on-call engineer hears of a problem is a customer reporting it. Cloud Monitoring finds the resources with no alarms, closes the gaps as code and keeps checking as your account grows.
Ask what is firing and where your gaps are through the AI Access Layer →
From blind spots to full coverage
Audit your coverage
We scan your AWS account for the resources CloudWatch can alarm on, and report which have alarms and which have none, by resource and by tag.
Get the coverage report
The gaps come back as a report, so you know exactly what is not being monitored, not a vague sense that something might be missing.
Deploy alarms as code
Alarms are defined in YAML and deployed through CloudFormation, with sensible defaults across your resource types, so monitoring is versioned and repeatable.
Add the checks AWS does not run
Lightweight Lambda checks cover HTTP, SSL certificate expiry and WebSocket endpoints, and emit straight to CloudWatch, without the cost of heavy canaries.
Route alerts by severity
Alarms route through SNS across four severity levels, Critical, Warning, Task and Informational, so the noise lands where it should.
Stay covered
Coverage is re-checked as your environment changes, so new resources do not slip through with no alarms on them.
Know what is not monitored, not just what is
A dashboard tells you about the resources you already alarm on. It says nothing about the ones you forgot. We audit your account for CloudWatch alarm coverage and report the gaps, so you know what alarms to create instead of guessing.
- Scans your account for the resources CloudWatch can alarm on
- Reports covered against uncovered, by resource and by tag
- The gap list feeds straight into the alarm configuration
- You start from what is missing, not from a blank page
Alarms as code, with defaults that make sense
Alarms are defined in YAML and deployed through CloudFormation, with sensible default alarms across your resource types and four levels of severity. Monitoring is versioned and repeatable, not clicked together in the console and forgotten.
- Default alarms across EC2, RDS, ECS, Lambda, API Gateway, CloudFront and more
- Four severity levels, Critical, Warning, Task and Informational
- Log metric filter alarms for the patterns that matter in your logs
- Alerts routed through SNS to the right place
The checks AWS does not run for you
AWS has no native WebSocket check, and CloudWatch Synthetics canaries are heavy and expensive for what most teams actually need. Our checks run as small Lambdas and emit straight to CloudWatch, so you monitor the things AWS leaves to you without the canary bill.
- HTTP availability, status code and response body checks
- SSL and TLS certificate expiry, before the certificate lapses
- WebSocket endpoint checks, which AWS has no native equivalent for
- Lightweight Lambdas that report to CloudWatch, not costly canaries
Built by base2Services
The monitoring we run on every AWS environment we manage, so a problem reaches us before it reaches your customers.
base2Services is an AWS Advanced Consulting Partner specialising in platform engineering and managed AWS operations. Cloud Monitoring is part of how we run AWS for people, not a side project. If you would rather not run it yourself, the team that built it runs it across your accounts and owns the response.
