Alarm and threshold manager for AWS auto-scaled databases

The specific moment: an ops engineer sets up CloudWatch alarms for a DynamoDB or ElastiCache cluster, auto-scaling kicks in during a traffic spike, and now every alarm threshold is wrong — they're either firing constantly or not firing when they should, because the thresholds were calibrated to a baseline that no longer exists. The engineer has to manually recalculate and reset thresholds after every significant scaling event, which can happen multiple times a week.

This gap exists because CloudWatch is a generic alerting layer that sits above all AWS services — it has no awareness of the semantic meaning of auto-scaling events for a specific database type. AWS isn't going to build database-specific alarm intelligence into CloudWatch because that would mean specializing a horizontal service. The user who suffers (the on-call engineer or DevOps person) is not usually the buyer, and the buyer (engineering manager, VP Engineering) only sees the downstream effect as alert fatigue or missed incidents — not as a tooling gap they can name.

What users are specifically asking for: 'better management of alarms, where threshold scale automatically with dynamically changing thresholds set by auto scaling.' This is a precise, solvable problem. No current alarm management layer does this for AWS database auto-scaling specifically — they track static thresholds or require manual reconfiguration.

This is a business because alert fatigue is expensive and recurring. A missed alarm on a database under load is a potential outage. An over-firing alarm trains engineers to ignore alerts, which is worse. The problem reappears every time a database scales, which for growth-stage SaaS companies is constant. The alternative is either an engineer manually babysitting thresholds or writing custom Lambda functions to recalibrate alarms — both of which cost real engineering time.

What to build

Build a service that watches AWS auto-scaling events for DynamoDB, ElastiCache, and MemoryDB clusters, and automatically recalculates and updates CloudWatch alarm thresholds proportionally when capacity changes — with a review UI showing what was adjusted and why.

Where to start

Target companies that have recently moved to DynamoDB on-demand pricing (which auto-scales aggressively by design), since they have the most frequent scaling events and are the most likely to have already felt this pain acutely.

The hard part

Proving value before a scaling event happens — the product sits idle until an auto-scale fires, so new customers can't experience the core benefit immediately, which makes the sales cycle dependent on timing or on the buyer already having been burned by this exact problem.

How it makes money

Monthly subscription priced per number of monitored database clusters, with a 30-day free trial that runs silently and shows a report of how many thresholds would have been recalibrated — making the value concrete before asking for payment.