The specific situation: a scheduled batch job fails at 2am, an engineer opens a ticket, and only then discovers that the underlying Marketplace software was undergoing vendor maintenance during that exact window. The complaint is precise — 'maintenance is done at times that impact scheduled functions, and we find out about this maintenance after opening support tickets rather than through proactive communication.'

This gap exists because vendor maintenance notifications typically live inside the vendor's own portal or status page, which nobody monitors continuously. AWS Marketplace itself does not aggregate or surface maintenance windows for third-party listings in any unified way. The person responsible for on-call at a company is watching their own infrastructure dashboards, not seventeen different vendor status pages.

The result is that engineers waste hours doing RCA work on failures that were actually caused by vendor maintenance they could have predicted and worked around — rescheduling jobs, alerting clients, or simply not deploying during that window. This is exactly what 'no backend support from Ubuntu MySQL, making it difficult to provide RCA reports to clients in critical situations' describes: the absence of information, not absence of software.

This is a business because the cost of a missed maintenance window isn't just lost time — it's a client-facing incident, a broken SLA, or a botched deployment. It recurs every maintenance cycle for every product in the stack, and no vendor has structural incentive to push their maintenance schedule into a competitor's monitoring tool.

What to build

Build a lightweight monitoring agent that scrapes and normalizes maintenance window announcements from AWS Marketplace vendor status pages and feeds them into PagerDuty, Slack, or email as calendar-style alerts with enough lead time to reschedule dependent jobs.

Where to start

Start with the ten Marketplace vendors that have the most public complaints about surprise maintenance on forums like Reddit and AWS re:Post, build manual monitoring for those ten first, and sign up five on-call teams who already know the pain before automating the ingestion layer.

The hard part

Vendor status pages have no standard format — some are hosted on Statuspage.io, some are buried in vendor forums, some are emailed to registered users only — so normalizing them requires a combination of scraping, parsing, and manual curation per vendor, which doesn't scale cleanly without significant upfront work.

How it makes money

Monthly subscription per team, priced per number of Marketplace products monitored; free tier for up to two products to drive organic adoption among individual engineers who then expense it.

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

More ideas in AWS Marketplace