Maintenance Window

A maintenance window is a period agreed in advance during which a service may be disrupted for planned work: an upgrade, a migration, a hardware replacement, a schema change that cannot be made online. The point of naming it is that the disruption stops being an incident. Customers were told, the work has an owner and a rollback, and the hours were chosen rather than arrived at. Two properties of the window matter more than its length. The first is who it belongs to. A provider's window is a right they reserved in the contract, and it may fall in the middle of your busiest hours because their busiest hours are elsewhere; if that matters, it is a negotiation to have before signing rather than a surprise to absorb later. The second is whether availability commitments exclude it. Planned maintenance is very often carved out of the promise, which means a service can be unavailable to you, entirely legitimately, without the figure on the page moving at all. That is not a trick, but it is a reason to read the exclusion list rather than the headline. The practice degrades in a predictable way. Windows that are never used stop being scheduled; windows that are used for everything become the only time anything ships, which makes each one large and risky; and a global product eventually discovers there is no hour that is quiet everywhere, so the window becomes a choice about which customers absorb the disruption. The honest response is to shrink what needs a window at all — doing more work in a way that keeps the service up — and to keep the remaining windows small, frequent, and announced far enough ahead that a customer can plan around them rather than react to them. It is also worth keeping a list of the windows your providers reserve, not only the ones you declare, because a dependency that takes its window at the same hour you take yours turns two routine pieces of work into one unplanned outage.