Maintenance & Version Lifecycle

## What a maintenance window is A managed service is software the provider operates on machines the provider owns, and both layers need routine work: fixes to the service engine, patches to the operating system underneath it, and firmware or hypervisor updates below that. A **maintenance window** is the recurring slot - typically expressed as a day of the week, a start time in a fixed time zone, and a duration in minutes - during which the provider is permitted to carry out that routine work on your instance. The window is a scheduling control, not an exemption. You are choosing **when** deferrable maintenance is attempted, not **whether** the service is ever patched or restarted. Providers let you nominate the slot, and if you do not nominate one the platform assigns one on your behalf - which is precisely why picking it deliberately is worth the five minutes it takes. The same idea appears on every managed product an estate runs, not only on databases: a managed cache, a managed message broker and a managed search cluster each carry a window of their own, and they are rarely aligned unless someone aligned them. ## What the provider may do inside it - Apply a **minor patch** to the service engine - a fix inside the same major version line. - Patch or reboot the **host** underneath the instance, or migrate the instance onto an already-patched host. - Update the layers you never see: firmware, the hypervisor, the storage fabric. - Carry out a change **you** requested and chose to defer, such as a resize or a setting that only takes effect after a restart. - On a replicated deployment, **promote the standby replica**, patch what used to be the primary, and leave it as the new standby. ## What your application sees The honest answer is a short interruption, not an invisible change. A typical sequence: 1. Open connections to the instance are severed, and transactions in flight roll back rather than completing. 2. The connection endpoint name stays the same, but on a replicated deployment it now resolves to the promoted replica's address. 3. New connections succeed as soon as the new primary accepts them. Clients holding pooled dead connections, or caching the previously resolved address, keep failing until they re-resolve and reconnect. 4. The old primary is patched in the background and rejoins as the standby, usually with no further client-visible event. | Deployment shape | What maintenance does | What the client sees | |---|---|---| | Single instance | Patch and restart in place | Connections dropped for the length of the restart | | Primary with a standby | Promote the standby, patch the old primary after | A brief failover, then service from a different machine | | Extra read replicas | Each replica patched on its own pass | Staggered short interruptions, one replica at a time | ## Choosing the window well - Pick **your** traffic trough, not the region's. An overnight slot in the region's local time may sit exactly on top of a nightly batch run. - Look at scheduled work, not only interactive traffic: reporting jobs, exports and reconciliation runs are the things that notice a dropped connection most. - In a regulated business, record the window in the change calendar, so an unattended restart is recognised as planned maintenance instead of being triaged as an incident in the middle of the night. - Keep one convention across the estate so whoever is on call knows when platform-generated noise is expected, and so two dependent services are not patched in the same minute. ## Where the window stops protecting you Three limits are worth stating plainly. - **Urgent work can land outside it.** Providers reserve the right to apply a critical fix, or an upgrade whose deadline has passed, outside the nominated slot. The window governs deferrable work. - **Deferral is finite.** A pending action you keep postponing is normally applied by a stated date, and deferred items stack: the window you have skipped three times becomes the window that does three things at once. - **The duration is not a downtime budget.** A one-hour window does not mean an hour of downtime, and it does not entitle you to an hour of it either. It bounds when work may start, not what that work costs you, and what you are owed if maintenance breaks the service is a separate question about the availability commitment. The practical consequence is that a maintenance window only helps if the application survives a restart at an arbitrary moment inside it. Connection pools that validate before handing a connection out, bounded connection lifetimes, and jobs that can be re-run without double-applying their effects turn a planned promotion into a log line. Without them, a sixty-second failover turns into a morning of manual recovery.