Monosasi

CloudWatch Events

Manage CloudWatch Events rules and targets with a Ruby DSL

Manages: Amazon CloudWatch Events
Language: Ruby
Package: monosasi
CLI: monosasi
Config file: Rulefile

The monosasi repository is archived on GitHub with no activity since 2019 and predates EventBridge's newer features, so evaluate Terraform or EventBridge-native tooling for new projects.

Rulefile

rule "cron" do
  state "ENABLED"
  description "my cron"
  schedule_expression "cron(0 17 ? * MON-FRI *)"
  target "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" do
    arn "arn:aws:lambda:ap-northeast-1:123456789012:function:hello-world"
    input_path '$.detail'
  end
end

In short

Monosasi is a Ruby command-line tool that manages Amazon CloudWatch Events as code. It exports your rules, schedules, event patterns, and targets into one file called a Rulefile. You review each change in Git, dry-run it, then apply it idempotently.

What is Monosasi?

Monosasi is a Ruby command-line tool in the codenize-tools family. It manages CloudWatch Events rules and their targets as code. You keep the rules in one text file, and Monosasi makes the account match it. This is the codenization approach: export, review, dry-run, apply.

Scheduled rules drift quietly. A cron time gets nudged in the console during an incident. A Lambda target gets swapped. Nobody records who did it or why. Monosasi turns that hidden state into a file you can read and diff. Each rule holds:

A schedule or event pattern - when the rule fires.
Targets - the Lambda functions or other resources it triggers.
State and description - whether it is on, and a note on what it does.

It pairs naturally with Meteorlog for CloudWatch Logs, so one team can run the same review workflow across their AWS event and monitoring config.

Key facts

Manages CloudWatch Events rules, schedules, event patterns, and targets.
One Ruby DSL file, the Rulefile, holds every rule in the account.
Filter runs by regex with --target, --include, and --exclude.
A dry-run prints the change set; the apply is idempotent.
Sits next to Radiosonde for a full events-and-alarms toolkit.
The repo is archived since 2019 and predates newer EventBridge features.

Illustration: Amazon CloudWatch Events managed as code with Monosasi

Getting started

Install and run Monosasi

Install

Install the monosasi gem (Ruby required).

$ gem install monosasi

Export current state

Pull the live CloudWatch Events configuration into a Rulefile.

$ monosasi -e -o Rulefile

Dry-run, then apply

Preview the diff, then apply the change for real.

$ monosasi -a --dry-run

Monosasi runs the export, review, apply loop for CloudWatch Events. First you export the live rules in export mode (the -e flag), adding --split for one file per rule. Commit the result to Git as your baseline.

After that, a schedule or target change is just an edit to the Rulefile in a branch. Run the apply with --dry-run to see the exact diff, then attach that output to the pull request. Once it is reviewed, apply for real. The apply is idempotent, so re-running is safe. A scheduled dry-run makes a solid drift detector: edit a rule in the console and the next run reports it.

Pro tip

Paste the dry-run output straight into the pull request. Changing a cron from daily to hourly can spike cost, and reviewers can see it before you merge.

Capabilities

What Monosasi can do

Rules and targets in one DSL

Each rule block holds its state, description, schedule or event pattern, and nested target blocks. The whole event wiring reads in one place.

Export existing rules

Export mode dumps your current CloudWatch Events config into the DSL. You can adopt Monosasi on a busy account in minutes.

Dry-run diffs

The dry-run prints every create, update, and delete before anything changes. Schedule edits get verified in the pull request and in CI.

Idempotent apply

Apply the same Rulefile twice and the second run does nothing. The tool only calls AWS for real differences.

Scoped runs with regex filters

The --target, --include, and --exclude options pick which rules a run touches. This helps when one account mixes managed and unmanaged rules.

Split export for large accounts

The --split option writes each rule to its own file. Diffs stay small and reviews stay focused when you manage many rules.

Handy Monosasi options

Common flags for scoping and reviewing a run.

Option	What it does
`--split`	Writes each rule to its own file for smaller diffs
`--target`	Limits the run to rule names matching a regex
`--include`	Only manages rules matching the pattern
`--exclude`	Skips rules matching the pattern
`--dry-run`	Prints the change set without calling AWS

In practice

When teams reach for Monosasi

Audit every cron schedule at once

Scheduled Lambda triggers and batch jobs build up over years. One export gives you a greppable list of every schedule and its target, far easier than paging through the console.

Code-review schedule changes

Moving a cron from daily to hourly has real cost and load effects. With Monosasi that change is a one-line diff in a pull request, with dry-run output attached.

Keep environments in sync

Apply the same Rulefile, with environment-specific ARNs, to staging and production. Event pipelines then behave the same, and re-running after a partial failure is safe.

FAQ

Monosasi questions, answered

Does Monosasi work with Amazon EventBridge?

Monosasi was written for CloudWatch Events, which later became EventBridge. Rules on the default event bus use the same underlying API. But the tool predates custom buses and other newer EventBridge features, so do not expect coverage of them.

What is the Rulefile?

The Rulefile is Monosasi's Ruby DSL file. Each rule block sets its state, description, schedule or event pattern, and one or more targets. You export it and apply it with the monosasi command.

Can I manage only some rules?

Yes. The --target, --include, and --exclude options take regular expressions that limit which rules a run considers. You can codenize your team's rules without touching rules owned by others.

Is Monosasi still maintained?

No. The repository is archived, with no activity since 2019. It stays handy for exporting and auditing existing rules. For new infrastructure, consider Terraform's aws_cloudwatch_event_rule and aws_cloudwatch_event_target resources, or EventBridge Scheduler.

How does the dry-run help day to day?

The dry-run prints the full change set without calling any mutating APIs. Teams paste it into pull requests and run it on a schedule, so console edits made outside the Rulefile get caught fast.