RDS Parameter Group "pending-reboot": Why It Never Clears on Its Own, How to Reboot Safely, Static vs Dynamic Parameters, Read Replicas, Aurora and the SQL Server Failover Trap

An RDS parameter group showing pending-reboot means you changed a parameter that only takes effect when the database restarts, and that restart has not happened yet. The new value is saved but not in use. To apply it, reboot the DB instance yourself: aws rds reboot-db-instance --db-instance-identifier mydb, or Actions > Reboot in the console, and the status changes to in-sync. The part that catches almost everyone: it will not fix itself. The next maintenance window does not reboot the instance to apply a pending parameter, so a database can sit in pending-reboot for months, quietly running on its old settings while everyone believes the change went live. Three more surprises are on this page: attaching a new parameter group needs a reboot even for parameters that are normally instant, a Multi-AZ SQL Server reboot with failover can leave the change unapplied, and on Aurora every instance in the cluster has to be rebooted, not just the writer.

Jake's shop booking app started refusing connections on busy Saturday mornings, and the error said the database had too many connections. Ethan raised max_connections in the RDS parameter group on Tuesday, saw the console accept it, and moved on. The next Saturday, the same error. When he finally looked at the database's Configuration tab, the parameter group said "pending-reboot," and had said so all week. "So the setting was there," Jake said, "but the database never read it?" Exactly that, and this page is how to make sure it does.

New to RDS? Our plain-English RDS guide explains instances, parameter groups and Multi-AZ in about ten minutes. The commands below work in any terminal with the AWS CLI; on Windows Command Prompt, replace the line-ending \ with ^.

What pending-reboot means, and why it never clears by itself

A DB parameter group is a named set of database settings (memory buffers, connection limits, timeouts, logging) that RDS applies to every DB instance attached to it. When you edit a parameter, RDS has to get the new value into a running database engine, and engines accept settings in two ways:

• Dynamic parameters can change while the database runs. RDS applies them straight away, and the instance stays in-sync.
• Static parameters are read only when the engine starts. RDS saves the new value and marks the instance pending-reboot: the change is waiting for the next start of the database service.

Here is the behavior that surprises people: nothing reboots the instance for you. The maintenance window is for engine patches and the changes you scheduled there, not for parameter changes, and the pending-reboot status does not trigger an automatic reboot in it. Unless something else happens to restart the instance (a scheduled engine upgrade, an instance class change, a failover), the old value stays in use indefinitely. The console shows the new value in the parameter group, which is why it looks applied.

You can see the status in the console on the DB instance's Configuration tab, next to the parameter group name. The possible values are:

"So it's like changing the thermostat setting while the heating is off," Jake said. "It's like writing the new setting on a sticky note," said Ethan. "The heating only reads the note when you restart it."

Find every instance waiting for a reboot

A parameter group is often shared by several databases, so one change can leave many instances pending. This command lists every DB instance in the Region with its parameter group and apply status:

aws rds describe-db-instances \
  --query "DBInstances[].[DBInstanceIdentifier, DBParameterGroups[0].DBParameterGroupName, DBParameterGroups[0].ParameterApplyStatus, DBInstanceStatus]" \
  --output table

Anything showing pending-reboot in the third column is running on old settings. Check each Region you use; the command only covers the Region in your profile. To see exactly which parameters you changed (and therefore what will change at the reboot), list the user-set parameters of the group:

aws rds describe-db-parameters --db-parameter-group-name shop-mysql-params --source user \
  --query "Parameters[].[ParameterName, ParameterValue, ApplyType, ApplyMethod]" --output table

The ApplyType column says static or dynamic for each parameter. Any static parameter in that list is a reason the instance is pending. Knowing what will change matters, because a reboot that applies a forgotten static change from months ago can surprise you with behavior nobody remembers asking for.

How to reboot and apply the change

Rebooting an RDS instance stops and starts the database service. It causes a short outage, usually a minute or two for a small instance and longer for a busy or large one, because the engine may need to recover transactions that were in flight. Plan it like any other short outage.

1. Check the instance is available. You cannot reboot while a backup, another modification or maintenance is running. If the status is modifying or backing-up, wait; our stuck in modifying guide helps if it never finishes.
2. Pick a quiet moment and tell the people who use the database. Applications reconnect after the reboot only if their connection pools retry, so check that yours do.
3. Reboot:

aws rds reboot-db-instance --db-instance-identifier shop-db

# wait for it to come back
aws rds wait db-instance-available --db-instance-identifier shop-db

4. Confirm the status changed to in-sync, then confirm the value from inside the database itself, which is the only proof that counts:

# status
aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[0].DBParameterGroups[0].ParameterApplyStatus"

# MySQL / MariaDB
SHOW VARIABLES LIKE 'max_connections';

# PostgreSQL
SHOW shared_buffers;

# SQL Server
SELECT name, value_in_use FROM sys.configurations WHERE name = 'max degree of parallelism';

What you reboot depends on how the database is deployed:

In the console, the same reboot is Databases > your instance > Actions > Reboot. Leave Reboot with failover unchecked unless you have a reason (see the SQL Server note below).

Ethan rebooted the booking database at 6:30 on a Wednesday morning, before the shop opened. Two minutes later SHOW VARIABLES LIKE 'max_connections' printed the new number. That Saturday the booking page stayed up. If you are raising max_connections for the same reason, our too many connections guide covers the safe limits for each instance size.

Still pending-reboot after rebooting? The six reasons

If you rebooted and the status still says pending-reboot, one of these is almost always the cause:

• You rebooted a different instance. A shared parameter group can be attached to several databases, and each one that uses it needs its own reboot. Run the listing command and reboot every instance that still shows pending-reboot.
• A read replica is still pending. Replicas have their own parameter group and their own status. Rebooting the source does not reboot the replica; reboot each replica separately. Replication resumes automatically afterwards.
• SQL Server Multi-AZ, rebooted with failover. On RDS for SQL Server, a reboot with failover reboots only the primary, which then becomes the secondary, and parameters might not be updated. A reboot without failover restarts both the primary and the secondary and applies the parameters. If you used failover and the change is still pending, reboot again without it.
• Aurora: another instance in the cluster is pending. Each Aurora instance, writer and readers, has its own status. See the Aurora section.
• The parameter group was edited again after the reboot. Someone (or an infrastructure-as-code pipeline) changed a static parameter after your reboot, so the instance is pending a newer change. describe-events shows when the parameter group was last modified.
• You checked while it was still applying. Give it a minute after the instance becomes available, then check again.

# what happened to this instance and its parameter group recently
aws rds describe-events --source-type db-instance --source-identifier shop-db --duration 1440
aws rds describe-events --source-type db-parameter-group --source-identifier shop-mysql-params --duration 1440

Switching to a new parameter group always needs a reboot

This one surprises people who know the static-versus-dynamic rule. When you attach a different parameter group to an instance (for example, moving from the default group to your own custom one, which is the only way to change any parameter, since default groups cannot be edited), RDS applies both the static and the dynamic parameters from the new group only after the instance reboots. Even a parameter that would normally change instantly waits.

aws rds modify-db-instance --db-instance-identifier shop-db \
  --db-parameter-group-name shop-mysql-params --apply-immediately

# the instance shows "applying", then "pending-reboot"; reboot to finish
aws rds reboot-db-instance --db-instance-identifier shop-db

Two details: --apply-immediately applies the association now instead of in the maintenance window, but it does not reboot for you; the reboot is still a separate step. And once the new group is attached and the instance has rebooted, later changes to dynamic parameters in that group apply straight away, as you would expect.

For a brand-new database, the cheapest moment to do this is right after creation, before anyone depends on it. Create a custom parameter group first and attach it when you create the instance, so the first reboot you ever need is planned, not urgent.

Static or dynamic? Check before you change

The reboot is only needed for static parameters, so check the type before you change anything. In the console, the parameter group's list shows an Apply type column; in the CLI, the ApplyType field does the same:

aws rds describe-db-parameters --db-parameter-group-name shop-mysql-params \
  --query "Parameters[?ParameterName=='max_connections'].[ParameterName, ApplyType, IsModifiable, AllowedValues]" --output table

When you change a parameter from the CLI, the ApplyMethod you pass decides what happens:

# dynamic parameter: apply now
aws rds modify-db-parameter-group --db-parameter-group-name shop-mysql-params \
  --parameters "ParameterName=max_connections,ParameterValue=250,ApplyMethod=immediate"

# static parameter (or a dynamic one you want to hold): apply at the next reboot
aws rds modify-db-parameter-group --db-parameter-group-name shop-mysql-params \
  --parameters "ParameterName=innodb_log_file_size,ParameterValue=536870912,ApplyMethod=pending-reboot"

A static parameter only accepts pending-reboot; asking for immediate on one is refused. A dynamic parameter accepts either, and choosing pending-reboot on purpose is a useful way to batch several changes into one planned restart. Which parameters are static depends on the engine and version: memory buffer sizes, log file sizes and anything loaded at startup (such as PostgreSQL's shared_preload_libraries) are typically static; connection limits, timeouts and logging levels are often dynamic. Always check ApplyType for your exact engine rather than guessing.

Aurora: reboot every instance in the cluster

Aurora uses two kinds of parameter group: a DB cluster parameter group for settings shared by the whole cluster, and a DB parameter group for each instance. A static change in either one shows as pending-reboot per instance, and each instance applies it only when it reboots. Rebooting the writer applies it to the writer; the readers stay pending until they reboot too.

# every member of the cluster with its cluster-parameter status
aws rds describe-db-clusters --db-cluster-identifier shop-aurora \
  --query "DBClusters[0].DBClusterMembers[].[DBInstanceIdentifier, IsClusterWriter, DBClusterParameterGroupStatus]" --output table

# reboot the readers first, one at a time, then the writer
aws rds reboot-db-instance --db-instance-identifier shop-aurora-reader-1
aws rds wait db-instance-available --db-instance-identifier shop-aurora-reader-1
aws rds reboot-db-instance --db-instance-identifier shop-aurora-writer

Rebooting readers first keeps the reader endpoint serving while each one restarts, as long as you have more than one reader. Our writer vs reader endpoint guide explains how your application's connections move during this.

When the status is failed-to-apply or incompatible-parameters

Occasionally a parameter group ends up in failed-to-apply, or the instance status shows incompatible-parameters. Both mean RDS cannot use the group's values on this instance: typically a memory-related value too large for the instance class (a buffer bigger than the instance has memory for, often after downsizing the instance), or a value that conflicts with another setting. Rebooting does not help, because the values themselves are the problem.

Look at the parameters you changed (describe-db-parameters --source user), reset the suspicious one to its default or to a value that fits the instance, and reboot. Formula-based defaults such as {DBInstanceClassMemory*3/4} scale with the instance size and avoid this when you resize later; fixed numbers copied from a bigger server are the usual culprit.

For IT admins: making pending-reboot visible

• Alert on it. Subscribe to RDS events for parameter group changes, or run the listing command on a schedule and alert on any pending-reboot older than a day, so changes do not silently wait for months.
• Batch static changes with ApplyMethod=pending-reboot and apply them in a planned reboot window, instead of rebooting for each change.
• Give each critical database its own parameter group if they need different settings, so one change cannot leave a dozen instances pending.
• Use Multi-AZ to shorten the outage of planned reboots, and remember the SQL Server failover caveat.
• Check after infrastructure-as-code changes. Terraform and CloudFormation update the parameter group but do not reboot the instance, so a pipeline that "succeeded" can leave the database pending.

Frequently asked questions

Ethan now runs the listing command every Monday morning, and it has caught two forgotten changes since. Jake's contribution was a line on the whiteboard next to the coffee machine: "Saved is not the same as switched on." Ethan says it is the best database advice he has ever been given by someone who does not use databases.

Revision note. Written October 17, 2026. "Well begun is half done," the proverb says; with static parameters, the reboot is the other half.