Emergency Changes & Maintenance Communication

Emergency Changes and Maintenance Communication

Sometimes a change cannot wait for the weekly review: a critical vulnerability is being exploited, a certificate expires tonight, a database is filling up, or a failed deployment is taking down checkout. Emergency changes exist for these moments. They are also where the worst outages begin — tired engineers, skipped reviews, no rollback plan, and nobody told the customer-facing teams that payment processing would pause for ten minutes.

A good emergency change process is fast because it is defined in advance: clear criteria for what qualifies, a small group empowered to approve immediately, a minimum set of safety checks that are never skipped, and communication templates ready to send. The same discipline applies to planned maintenance: people affected by a change deserve timely, specific notice, and a clear signal when it is done.

TL;DR

Classify changes as standard (pre-approved, low risk), normal (reviewed), or emergency (needed now to restore or protect service).
Define emergency criteria in advance; "urgent for a deadline" is usually not an emergency.
Use an emergency change authority or on-call approver for immediate approval, with a second engineer reviewing every command or diff.
Require rollback evidence before acting: a backup, snapshot, previous version, or tested reversal.
Communicate to affected services, support, and customers — before when possible, during, and after — through templates and a status page.
Verify after the change, complete the record within a day, review emergencies, and track how often they happen.

Quick Example

An emergency change record, created at the start and completed afterward:

A planned maintenance notice template:

Core Concepts

Change Types

Mature teams move most changes into standard by automating them with tests, gradual rollout, and automatic rollback; the remaining manual changes get proper review, and emergencies become rare. See Change Management.

Emergency Criteria

Define what qualifies before you need it, for example:

Restoring or protecting a service during an active incident.
Mitigating a security vulnerability that is being exploited or is critical and exposed.
Preventing imminent, likely failure (disk full in hours, certificate expiring).
A legal or regulatory obligation with an immediate deadline.

Business pressure to ship a feature before a demo is a prioritization problem, not an emergency. Track requests that were rejected as emergencies; they reveal planning gaps.

Expedited Approval and Safety Checks

The emergency change authority is a small rota of people (often the incident commander or a senior on-call engineer) who can approve immediately by phone or chat. Speed comes from removing meetings, not from removing safety:

Emergency changes made during incidents are coordinated by the incident commander; see On-Call Operations and Incident Command and Incident Management.

Rollback Evidence

Before acting, confirm a way back: database backups or snapshots verified as restorable, previous artifact versions available in the registry, configuration in version control, and — for schema changes — compatibility so the previous application version still works. See Release Rollback and Database Compatibility.

Maintenance Communication

Planned maintenance follows notice periods defined in contracts and SLAs (commonly days to weeks for customer-impacting work), with reminders shortly before. Emergency maintenance communicates as early as possible and updates on a regular cadence. Always announce completion — silence leaves people unsure whether problems are related. Write for the reader's impact ("exports unavailable"), not internal system names. See Service Desk Operations.

Verification and Review

After the change: run smoke tests and synthetic checks, watch error rates, latency, and business metrics against defined success criteria, and keep the rollback ready for a set observation period. Complete the change record within one business day.

Review emergency changes regularly — weekly or monthly — asking whether the emergency was justified, whether safety checks happened, what the root cause was, and how to prevent recurrence. Track emergency change rate, change failure rate (see DORA Metrics), and unauthorized changes found in audits.

Best Practices

Decide the Process Before the Emergency

Publish criteria, approvers, minimum safety checks, and communication templates, and practice them.

Pair Every Emergency Change

A second engineer reviewing commands catches the mistakes stress produces.

Communicate Early and Specifically

Tell affected people what will happen, when, and what it means for them — then confirm when it is over.

Turn Emergencies Into Standard Changes

Automate recurring emergency fixes (certificate renewal, disk cleanup, patching) so they stop being emergencies.

Common Mistakes

Emergency as a Shortcut

No Way Back

Silent Maintenance

FAQ

What is an emergency change?

A change that must be implemented faster than the normal change process allows, to restore service, prevent imminent failure, or mitigate a serious security risk, approved through an expedited path.

Who approves emergency changes?

A small, predefined emergency change authority — often senior on-call engineers or incident commanders — who can approve immediately, with documentation completed after the change.

What should never be skipped in an emergency change?

Peer review of what will be executed, confirmed rollback capability, a minimal scope, communication to affected teams, and a record of what was done.

How much notice should customers get for planned maintenance?

Whatever contracts and SLAs require — commonly several days to two weeks for impactful work — with a reminder shortly before and updates when it starts and ends.

How do we reduce the number of emergency changes?

Automate recurring operational tasks, improve monitoring so problems are caught earlier, plan work to avoid deadline-driven urgency, and review each emergency for prevention actions.