Radiosonde
CloudWatch AlarmsManage CloudWatch Alarms as code with a Ruby DSL
- Manages
- Amazon CloudWatch Alarms
- Language
- Ruby
- Package
- radiosonde
- CLI
- radiosonde
- Config file
- Alarmfile
alarm "alarm1" do
namespace "AWS/EC2"
metric_name "CPUUtilization"
dimensions "InstanceId"=>"i-XXXXXXXX"
period 300
statistic :average
threshold ">=", 50.0
evaluation_periods 1
actions_enabled true
alarm_actions []
ok_actions []
insufficient_data_actions ["arn:aws:sns:us-east-1:123456789012:my_topic"]
endRadiosonde is a command-line tool that manages Amazon CloudWatch Alarms as code. You keep each alarm's metric, threshold, and notification actions in a Ruby file called an Alarmfile, then apply it. It exports existing alarms, shows a dry-run diff, and applies changes idempotently.
What is Radiosonde?
Radiosonde manages Amazon CloudWatch Alarms as code. Each alarm is declared in a Ruby file called an Alarmfile. The radiosonde command diffs the file against the alarms that really exist and updates CloudWatch to match.
Alarm config decays quietly. Thresholds get tweaked in the console during an incident. Alarms are left behind for hosts that no longer exist. Nobody knows which alarms page and which are noise. Radiosonde puts the whole alerting setup into version control. Every threshold change gets an author, a review, and a revert path. That is codenization for your monitoring.
One Alarmfile block holds a full alarm:
- Metric details: namespace, metric name, and dimensions
- Trigger: threshold, period, statistic, and evaluation periods
- Actions: SNS topics for alarm, OK, and insufficient-data states
It suits teams standardizing monitoring across services. For Datadog monitors, its sibling Barkdog works the same way, and Meteorlog covers CloudWatch Logs.
- Manages CloudWatch Alarms as code, one block per alarm.
- Every alarm lives in a single Alarmfile tracked in Git.
- Notification actions are SNS topic ARNs written right in the file.
- Works with custom metrics, not just built-in AWS namespaces.
- Dry-run shows every alarm to be created, changed, or deleted first.
- Archived since 2018, so composite alarms and metric math are not covered.
Install and run Radiosonde
Install
Install the radiosonde gem (Ruby required).
$ gem install radiosondeExport current state
Pull the live CloudWatch Alarms configuration into a Alarmfile.
$ radiosonde -e -o AlarmfileDry-run, then apply
Preview the diff, then apply the change for real.
$ radiosonde -a --dry-runRadiosonde follows the export, review, apply loop. Start with radiosonde -e to export every alarm in the region into one file and commit it. Reading that first export is often an audit by itself: duplicate alarms, dead instance dimensions, and alarms with no actions all stand out. It is the standard export, review, apply workflow.
Alerting changes then happen as edits in a branch. Raise a threshold, add an SNS action, or delete a stale alarm, then run radiosonde -a --dry-run to see the exact create, update, and delete set. Attach that output to the pull request so reviewers approve the real effect. After merge, radiosonde -a applies the file idempotently, so running it again changes nothing. A scheduled dry-run catches alarms edited in the console mid-incident.
Loop over a list of instances or services in the Alarmfile to stamp the same baseline alarms everywhere. Adding one entry then gives a new service complete monitoring by default.
What Radiosonde can do
Export existing alarms
radiosonde -e dumps every CloudWatch Alarm in the region into the DSL. You can adopt alarms-as-code on an account that already has monitoring.
Dry-run diffs
radiosonde -a --dry-run shows which alarms would be created, changed, or deleted before anything happens. Threshold tuning becomes reviewable instead of ad hoc.
Complete alarm definitions
The DSL covers namespace, metric, dimensions, period, statistic, threshold, evaluation periods, and actions_enabled. The full shape of an alarm sits in one readable block.
Notification actions as code
alarm_actions, ok_actions, and insufficient_data_actions take SNS topic ARNs directly. Who gets paged is documented and versioned, not tribal knowledge.
Ruby for repetitive alarms
Because the Alarmfile is Ruby, you can generate the same alarm across a list of instances or services with a loop. Thresholds stay consistent by construction.
| Field | Controls |
|---|---|
namespace / metric_name | Which metric the alarm watches |
dimensions | Which resource, such as an instance id |
threshold / statistic | When the alarm trips |
period / evaluation_periods | How long the breach must last |
alarm_actions / ok_actions | Which SNS topics get notified |
When teams reach for Radiosonde
Reviewable threshold tuning
Alert fatigue usually comes from thresholds changed casually and never revisited. With Radiosonde, raising a CPU alarm from 50% to 70% is a diff with an author and a reason in the commit. You can revert it the moment it hides a real problem.
Standardizing alarms across services
Generate the same baseline alarms, like CPU, status checks, and queue depth, for every service from a Ruby loop. New services get full monitoring by adding one entry, and gaps between teams disappear.
Cleaning up stale monitoring
Accounts collect alarms pointing at terminated instances, stuck forever in INSUFFICIENT_DATA. The export makes them easy to spot, and deleting them is a reviewed diff, not a risky console spree.
Rebuilding alarms across accounts
An Alarmfile exported from one account can be applied to another. Reproducing a proven alerting setup in a new account or region is straightforward, instead of rebuilding it by hand.