Reading RDS maintenance notices

“Amazon RDS Maintenance Notification” is the mail that arrives when an update to the database's operating system or engine, or a hardware swap, has been scheduled. It usually comes with a short outage, so before the deadline you have to work out whether the customer needs warning.

Last updated: 2026-09-22

The three things an RDS maintenance notice tells you

Reading the body, three things matter: what is being updated, when, and whether it stops the database. A required operating system update or a minor engine version means a few minutes of downtime on Single-AZ, and a short disconnection through failover on Multi-AZ. A hardware swap behaves the same way.

The “when” is the start time of that instance's maintenance window, written in UTC. It has to be converted to your own time zone, and that is where the mix-up happens: the conversion can move the day, and what looked like late Saturday night turns out to be early Sunday morning.

What the mail makes easy to miss

Most of these notices offer two choices — apply the update now, or defer it to the next window — and both are made from the RDS console. A required update does not go away when it is deferred, though: it gets applied in the end. One mail can also list several instances, and when production and staging are mixed into the same notice, production is the part that gets missed.

Look after several customers' accounts and the same subject line arrives once per customer. Working out each time, from the account ID in the subject and the instance name in the body, whose production database this one is about is the part that takes the longest.

What Sabaki does with them

Sabaki pulls the account ID and the instance name out of the body, files the notification under that customer, and shows the start of the maintenance as a deadline in your own time zone. The summary says which instance stops, when, and for how long; the explanation says how the impact differs between Single-AZ and Multi-AZ, and what the options are for applying it early or deferring it.

Example: the mail that arrives, and what Sabaki shows

The subject and body imitate a real notification. Account IDs and dates are fictional.

The mail that arrives (English)
From
Amazon Web Services <no-reply-aws@amazon.com>
Subject
Amazon RDS Maintenance Notification [AWS Account: 123456789012]

Dear Amazon RDS Customer,

We are contacting you to inform you that a required operating system update is scheduled for your Amazon RDS DB instance(s) in the ap-northeast-1 region: prod-db-01 (db.m6g.large, Single-AZ).

The update will be applied during your maintenance window starting Sat, 2026-10-17 18:00 UTC. Your DB instance will experience a brief downtime of a few minutes while the update is applied. You may apply the update immediately or defer it to a later maintenance window from the RDS console.

What Sabaki shows (English)
Action requiredCompany A (online shop)123456789012 (Company A, production)Due: 2026-10-18 03:00 (UTC+9)

The RDS instance prod-db-01 in Company A's production account has a required operating system update scheduled: it stops for a few minutes during the maintenance window that starts on Sunday 18 October at 03:00 (UTC+9).

This is a Single-AZ setup, so the database will refuse connections for a few minutes while the update runs. That affects order processing on the shop, so tell the customer in advance and check the slot suits them. If it does not, the update can be applied early or deferred to the next window from the RDS console. It is a required update, though, so deferring it only moves the moment it lands.

On a Multi-AZ instance the explanation would talk about “a few tens of seconds of disconnection through failover” instead. On a staging environment, marking it “No action needed” with the reason in the ledger is the whole job.

From the notice to the message you send on

The summary and the explanation go straight into the draft of the message you send the customer. Put that customer's Slack channel on the other end and they see when and for how long the database stops the moment the notice arrives, leaving whoever is on it only the rest to add. What was done stays in the response ledger, so whether the warning actually went out can be checked later.

A reason to revisit the maintenance window

If every notice ends with you working out whether the maintenance falls in the middle of the night, the real fix is to move the instance's own maintenance window to something that suits the business. The explanation gives the window's start time in your own time zone, which is what makes that review possible.

Forward one AWS notification and it comes back explained

The Free plan covers one account and one seat, with no credit card. Nothing changes on the AWS side, and no access keys are registered.

Related questions

Related guides

If this helps, pass it on to someone who needs it.