The moment an engineering team runs databases across more than one region — or has read replicas, standby instances, and a primary — scheduling a maintenance window becomes a spreadsheet problem. Users explicitly say they 'had to manually calculate the time offset for our maintenance window' and that 'need to do updations for both the availability zone simultaneously results in downtime.' The console gives you a time picker in UTC. It does not tell you whether you've accidentally overlapped with your replica's window, whether your failover standby is in a different AZ that patches on a different schedule, or whether the combination of two simultaneous maintenance windows removes your redundancy during the overlap.

This gap persists because AWS's incentive is to let you set a window and move on. The complexity of coordinating windows across a fleet is entirely the customer's problem — AWS treats each instance's window as an isolated setting. The buyer (a head of infrastructure or a DBA) often sets these once during initial setup and never revisits them, but the on-call engineer discovers the gap when a patch night turns into a 20-minute outage because both the primary and standby patched concurrently.

Teams without this end up either over-engineering their maintenance process (running their own scripts to stagger windows, manually tracking AZ assignments in a wiki) or under-engineering it (accepting outages as a cost of running managed databases). Neither is sustainable as the fleet grows.

The need recurs every time the fleet changes — a new region, a new replica, an engine upgrade cycle, or a compliance requirement that restricts maintenance to a specific time band. Each change re-opens the coordination problem.

What to build

Build a service that connects to a team's AWS account via read-only IAM role, maps all RDS and Aurora instances with their maintenance windows, replica relationships, and AZ assignments, and flags unsafe window configurations (concurrent primary/standby patches, windows that overlap across regions during peak hours) with specific recommended adjustments.

Where to start

Target companies that recently had a production outage traced to overlapping maintenance windows — they're already motivated, have an internal post-mortem that justifies the spend, and need something to show leadership that the problem is fixed. Reach them through SRE and DevOps communities where post-mortems are shared publicly.

The hard part

Getting teams to grant even read-only IAM access to a third-party tool requires security review, which kills early sales velocity — the product needs a credible self-hosted deployment option from day one to close the first 10 customers.

How it makes money

Monthly subscription per AWS account connected, tiered by number of database instances monitored, with a free tier capped at five instances to cover small teams and drive word of mouth.

See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Relational Databases.

More ideas in Relational Databases