Maintenance Window Conflict Checker

{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }}

Maintenance windows:

Times without an offset use this browser’s local timezone. Data stays in this browser.

Conflict scope:

The default flags shared service, CI, dependency, or owner context.

Concurrency threshold:

Use the maximum simultaneous change load accepted by the review team.

windows

Guard buffer:

Use this for handoff, rollback, or monitoring guard time.

minutes

Ignored statuses:

Leave blank to evaluate every valid row.

Blackout windows:

Add approved freezes or business blackout periods that must be checked independently.

Priority	Changes	Overlap	Shared context	Owners	Next action	Copy
{{ row.severity_label }}	{{ row.change_a }} / {{ row.change_b }}	{{ row.overlap_label }} {{ row.window_label }}	{{ row.reason }}	{{ row.owner_a }} / {{ row.owner_b }}	{{ row.action }}
No conflicts matched the current scope. Confirm CMDB relationships and operational capacity before approval.

{{ row.owner }} · {{ row.state }}

{{ row.window_count }} window{{ row.window_count === 1 ? '' : 's' }} · {{ row.conflict_count }} conflict{{ row.conflict_count === 1 ? '' : 's' }} · next conflict {{ row.next_conflict }}

Reconcile these local owner signals with the authoritative change calendar and assignment groups.

Change	Start	End	Service	Owner	Risk	Status	Copy
{{ row.id }}	{{ row.start }}	{{ row.end }}	{{ row.service }}	{{ row.owner }}	{{ row.risk_label }}	{{ row.status }}

Maintenance schedules become risky when several valid changes compete for the same people, service, configuration item, dependency, or recovery window. Two teams can each have an approved change and still create a combined outage by restarting both sides of a dependency, exhausting shared capacity, or leaving nobody available to decide which rollback comes first.

Time overlap is only the first test. A review also needs context about what is changing, who owns it, which environment is affected, and what other systems it depends on. A database patch and an unrelated documentation release may safely run together; two changes to the same payment path may need sequencing even when different teams own them.

Maintenance scheduling concerns and their practical effect
Concern	What it reveals	Typical response
Actual overlap	Implementation periods run at the same time.	Sequence, move, or explicitly accept the combined risk.
Guard-buffer contact	Implementation periods do not overlap, but handoff, rollback, or monitoring time collides.	Keep separation visible or assign a clear handoff owner.
Blackout conflict	A change enters an approved freeze or protected business period.	Move the change or obtain the required exception.
Concurrency spike	More changes are active than the review team accepts at once.	Reduce simultaneous load even when pairs do not share context.

Schedule boundaries need a consistent convention. Treating each window as starting at its listed time and ending just before its end time allows one change to finish exactly when another begins without creating an actual overlap. A guard buffer deliberately expands both sides of every window, turning some boundary touches into near misses that deserve operational attention.

A conflict report is a decision aid, not a change-approval system. Missing dependencies, inconsistent service names, stale statuses, local-time assumptions, and unrecorded owner commitments can all hide real risk. The schedule should be reconciled with the authoritative change records and the people accountable for implementation and rollback.

How to Use This Tool:

Use one consistent export or planning snapshot so service names, owners, environments, dependencies, and times can be compared across every row.

Paste Maintenance windows with start and end times. A recognized header can map change ID, service, owner, environment, configuration item, dependencies, risk, status, and summary; comma, tab, pipe, and semicolon delimiters are accepted.
Choose Conflict scope. The default matches time overlap with shared service, configuration item, dependency, or owner; narrower and broader scope choices change which pairs qualify.
Set the Concurrency threshold to the maximum simultaneous change load accepted by the review team. A segment is flagged only when active changes exceed that number.
Add a Guard buffer for rollback, monitoring, or handoff time. Enter ignored statuses only when those rows should be removed before every comparison.
Paste approved Blackout windows when freezes need an independent check. Resolve invalid rows, then work through Critical and High conflicts, owner follow-up, and over-threshold timeline segments.

Interpreting Results:

The overall status follows the most urgent pair: any Critical conflict produces Critical conflicts; otherwise any High pair produces High-priority conflicts. Lower-severity pairs produce Review conflicts. A clear status means no pair matched the selected scope and buffers, not that the schedule is operationally safe.

Use actual overlap for simultaneous implementation time and buffer overlap for the wider handoff or rollback exposure.
Check the stated reason before moving a change. Same owner, same service, shared dependency, and same environment represent different coordination problems.
Compare max concurrency with the threshold. A value equal to the threshold is allowed; only a greater value is flagged.
Investigate invalid and ignored row counts. A clean conflict ledger is weak evidence if relevant changes were skipped.

Technical Details:

Each valid change becomes a half-open interval from its start time up to, but not including, its end time. This convention makes back-to-back windows non-overlapping at the shared boundary. Times without an explicit offset are parsed in the browser's local timezone; offset-bearing values are converted by the browser and displayed in local time.

Formula Core:

For windows A and B, actual overlap is the positive part of the earlier end minus the later start. Dividing milliseconds by 60,000 gives minutes.

{overlap}_{A B} = \frac{\max (0, \min (e_{A}, e_{B}) - \max (s_{A}, s_{B}))}{60000}

A guard buffer of b minutes moves each start earlier and each end later before a second overlap calculation. When adjusted intervals intersect but the original intervals do not, the result is buffer-only.

s_{i}^{'} = s_{i} - 60000 b, e_{i}^{'} = e_{i} + 60000 b

Concurrency is counted on exact schedule segments formed by every start and end boundary. A segment is over capacity only when its active-window count is strictly greater than the selected threshold.

C (t) = \sum_{i}^{n} 1 [s_{i} \leq t < e_{i}], flag \Leftrightarrow C (t) > T

Rule Core:

Maintenance conflict scope rules
Scope	A time-intersecting pair qualifies when it shares
Service, CI, dependency, or owner	Service, configuration item, dependency, or owner
Service, CI, or dependency only	Service, configuration item, or dependency
Environment sensitive	Service, configuration item, dependency, owner, or environment
Every time overlap	Any schedule overlap, with shared context retained when present

Maintenance conflict severity rules
Condition	Severity
Actual blackout intersection, or either change is Critical risk	Critical
High-risk change plus shared service, CI, dependency, or at least 30 minutes of actual overlap	High
Shared service, CI, dependency, or owner; or at least 30 minutes of actual overlap	Medium
Other qualifying actual overlap, or a buffer-only change pair	Low
Buffer-only contact with a blackout window	High

Risk aliases such as sev1, p1, and critical normalize to Critical; equivalent groups map through High, Medium, and Low. Ignored statuses are removed before conflict, concurrency, and owner calculations. Blackout rows match every environment when their environment is blank or all, otherwise they match the normalized environment exactly.

The schedule accepts a concurrency threshold from 1 through 20 and a whole-minute buffer from 0 through 240. Maintenance source is limited to 524,288 characters and blackout source to 262,144. Invalid rows are skipped when at least one valid window remains, and the timeline is capped at 260 exact segments with a warning when that cap is reached.

Limitations and Privacy Notes:

Schedule and blackout text stays in the browser during analysis. The conflict model depends entirely on the supplied rows and uses a transparent local severity heuristic rather than an external change-management standard.

Times without offsets inherit the current browser timezone and its daylight-saving rules. Use explicit offsets when participants work across zones.
Name matching is normalized text matching. Aliases, renamed services, or missing dependency records can prevent a real relationship from being detected.
Concurrency counts changes, not their actual demand for engineers, bandwidth, failover capacity, or support coverage.
Approval, recurrence, calendars, maintenance-window exceptions, and live ticket state are not fetched from external systems.

Worked Examples:

Shared API and database dependency

Change A runs from 10:00 to 11:00 with High risk. Change B runs from 10:30 to 11:30 with Medium risk. Both affect the API service and depend on the same database. Their actual overlap is 30 minutes, so the pair is High. With a concurrency threshold of 1, the 10:30 to 11:00 segment has two active changes and is also over capacity.

Back-to-back windows with rollback space

One change ends at 11:00 and the next begins at 11:00. With no guard buffer, the half-open intervals do not overlap. A 15-minute buffer expands both windows, creating a buffer-only near miss. For a normal change pair that is Low severity; if the second interval is a blackout boundary, the buffer-only contact is High.