How Cloud Watchdog works
and how to set it up.

Cloud Watchdog is a watchdog (literally) for your AWS bill. It connects read-only into your AWS account, watches your live CloudWatch metrics every few minutes, and sends a Slack message + email the moment one of your resources starts behaving like it's about to cost you a lot of money.

Three things happen behind the scenes, all on a schedule:

Free is for trying it out on a single AWS account with a handful of alert rules and the top idle resources visible. Starter adds more accounts, more rules, the full idle list, and the actually-stop-the-thing circuit breakers.

You'll go through five short steps. No prior AWS or DevOps experience required — the trickiest bit is uploading a YAML file in the AWS Console, and we provide a one-click download for that.

1. 01

   Sign up for the dashboard

   2 min

   Head to cloudwatchdog.online/sign-up and create your account with Google or email. You'll land on an empty workspace called "My workspace".

   No credit card needed. Free plan is active by default.

2. 02

   Deploy the IAM role in your AWS account

   5 min

   Cloud Watchdog never stores AWS access keys. Instead, you give it a tiny IAM role inside your AWS account that it can assume short-lived. You do that with a CloudFormation template we ship for free.

   1. Pick the right template (see below): Read-only for the Free plan, Circuit-breaker for Starter.
   2. AWS Console → CloudFormation → Create stack → With new resources → upload the YAML.
   3. Stack name: CloudWatchdog (or whatever you like).
   4. When status reaches CREATE_COMPLETE, copy the RoleArn from the Outputs tab.
   5. Back in Cloud Watchdog → /onboarding/cloud → paste the ARN. We run an automatic permissions probe and tell you within ~10 seconds whether everything's wired correctly.
3. 03

   Wire up Slack + email so alerts actually reach you

   2 min

   /settings → Notifications. Paste a Slack incoming-webhook URL (created in your Slack workspace under "Apps → Custom Integrations → Incoming Webhooks") and add an email address. We send a test ping to confirm both work before saving.

4. 04

   Create your first alert rule

   1 min

   /alert-rules → Create rule. Pick the service (Lambda / EC2 / RDS / NAT), metric, threshold, and time window. For most rules a 10-minute window works well — short windows often miss CloudWatch's ~5-minute publish cadence.

   The form gates this for you — if you pick EC2 or RDS, the minimum window jumps to 10 min. Lambda can stay at 2 min because its metrics publish in near-real time.

5. 05

   Tag resources (only if you want circuit breakers)

   2 min per resource

   Skip this step for Free.If you're on Starter and want the system to actually stop a Lambda or EC2 instance when it goes haywire, you have to opt resources in with two tags. See the tag section below for the exact key/value pairs.

Cloud Watchdog needs to read your AWS resources to find waste and watch metrics. For the optional circuit breakers, it also needs a narrow set of write permissions (only on resources you've opted in by tag). Both come from a CloudFormation template we publish on GitHub for you to audit before deploying.

Download the right template for your plan

Deploy the template (the screen-by-screen part)

1. AWS Console → search CloudFormation → make sure your region is one your resources actually live in (e.g. us-east-1).
2. Click Create stack → With new resources (standard).
3. Pick Upload a template file, click Choose file, and select the YAML you downloaded above. Click Next.
4. Stack name: CloudWatchdog (or CloudWatchdog-CircuitBreakerif deploying the breaker template as a second stack). Leave parameters at their defaults — they auto-fill from Cloud Watchdog's onboarding page.
5. Two more clicks of Next (you can skip tags + advanced options).
6. Tick the IAM capabilitiescheckbox at the bottom of the review page — that's AWS reminding you the stack creates a role. Click Submit.
7. Wait ~30 seconds. Status flips from CREATE_IN_PROGRESS to CREATE_COMPLETE.
8. Open the Outputs tab. Copy RoleArn — it looks like arn:aws:iam::123456789012:role/CloudWatchdog-Role-XYZ. Paste it into /onboarding/cloud in Cloud Watchdog and click Test & save.

Cloud Watchdog refuses to act onany AWS resource — even with the circuit-breaker IAM role attached — unless you've marked the resource with two opt-in tags. This is the second of three safety checks (alongside the IAM policy itself and the production-environment guard). Pure detection / read-only rules need no tags at all.

How to add the tags

AWS Console → EC2 (or Lambda / ECS, etc) → select your resource → Tags tab → Manage tags → Add tag. Or use the AWS CLI:

aws ec2 create-tags \
  --resources i-0abc1234567890 \
  --tags Key=env,Value=dev \
         Key=cloudwatchdog:managed,Value=true \
         Key=cloudwatchdog:auto-stop,Value=true

After tagging, click Sync inventory on /resources — the new tags land in our DB within 10 seconds, and the next alert that opens will plan an action successfully.

Two channels, both equally important. Most teams set them up together — Slack for "everyone sees it instantly", email for "the on-call person in another timezone has a paper trail at 3am".

A rule is a sentence of the form "if <metric> for <service> goes <operator> <threshold> over <window> minutes, do <action>." Two flavors:

The metric library — 44 metrics across 7 services

When you pick a service, the metric dropdown only shows metrics that make sense for it — and each metric carries its own unit. Pick CPU, type 70, the form labels it %. Pick NetworkOut, type 10, the form labels it MB(and converts to bytes when it talks to CloudWatch, so you don't do the math). Coverage:

• EC2 (8 metrics): CPU, NetworkIn/Out, NetworkPacketsIn/Out, MetadataNoToken, CPUCreditUsage, CPUCreditBalance.
• EBS (7 metrics): queue length, R/W throughput, R/W ops, idle time, BurstBalance.
• RDS (7 metrics): CPU, FreeableMemory, DatabaseConnections, R/W IOPS, FreeStorageSpace, ReplicaLag.
• Lambda (6 metrics): Invocations, Errors, Duration, Throttles, ConcurrentExecutions, IteratorAge.
• S3 (5 metrics): BucketSizeBytes, NumberOfObjects, AllRequests, 4xx, 5xx.
• NAT (6 metrics): BytesOutToDestination, BytesInFromDestination, ActiveConnectionCount, ErrorPortAllocation, PacketsDropCount, IdleTimeoutCount.
• ELB / ALB (4 metrics): RequestCount, TargetResponseTime, HTTP 5xx, HTTP 4xx.

Each resource also has its own dedicated detail page (open any row on /resources) that renders every catalog metric as its own 24h graph, with a one-click "Set alert rule for this metric" CTA next to each.

Resource scope — one rule, many instances

Every Usage rule asks which resources? Two modes:

• All current + future— the rule applies to every resource of the chosen service, including ones you create tomorrow. Best for "every Lambda must obey the runaway-invocation rule".
• Pick specific resources — a search-box + checkbox list lets you scope to a hand-picked subset. New resources are not auto-included.

CloudWatch Alarms force a 1:1 alarm-per-resource model — 80 EC2 instances meant 80 nearly-identical alarms. Here it's one rule.

Auto-suggest threshold

Click the Auto-suggest from last 7dbutton next to the Threshold input. Cloud Watchdog pulls every cached sample for the matched resources, computes P50 / P95 / P99, and fills in P95 × 1.2 rounded to a clean number. You can refine from there — it's a starting point, not a lock-in. Needs ≥10 samples to fire.

Suggested rules from your inventory

Once inventory sync is running, the /alert-rules page shows a Suggested for your inventory card with 2–4 high-value rules you probably want — based on what services you actually run. One click pre-fills the create form.

Action modes — three to pick from

A circuit breaker is what we call a rule whose action mode is anything other than "Alert only". When the threshold trips, Cloud Watchdog can actively halt the resource that's bleeding money. It's gated by three safety checks on top of the IAM policy:

What each action actually does