Maintenance Window Conflict Checker

Maintenance Conflict Snapshot

{{ criticalConflictCount }} critical {{ highConflictCount }} high {{ parsedWindows.length }} window{{ parsedWindows.length === 1 ? '' : 's' }} {{ ownerBriefRows.length }} owner{{ ownerBriefRows.length === 1 ? '' : 's' }} {{ validationMessages.length }} note{{ validationMessages.length === 1 ? '' : 's' }}

Maintenance windows:

Header is optional. Default order is id, start, end, service, owner, environment, CI, dependencies, risk, status, summary.

Conflict scope:

Use the default for CAB checks where owner, CI, service, or dependency overlap matters.

Concurrency threshold:

Set the review threshold for simultaneous approved changes.

windows

Review the schedule source

{{ message }}

Buffer check:

Use 0 for exact overlaps, or add handoff and rollback guard time.

min

Ignored statuses:

Leave blank to evaluate every valid row.

Blackout windows:

Optional freeze periods to flag even when no other maintenance window overlaps.

Change	Start	End	Duration	Service	Owner	Environment	Risk	Status	Issues	Copy
{{ row.id }}	{{ row.startDisplay }}	{{ row.endDisplay }}	{{ row.durationDisplay }}	{{ row.service }}	{{ row.owner }}	{{ row.environment }}	{{ row.riskLabel }}	{{ row.status }}	{{ row.issueCount }}
No maintenance windows parsed Paste CSV, TSV, pipe, or semicolon rows, or load the sample schedule before exporting this ledger.

Change A	Change B	Severity	Overlap	Conflict window	Services	Reason	Recommended action	Buffer	Copy
{{ row.changeA }}	{{ row.changeB }}	{{ row.severityLabel }}	{{ row.overlapDisplay }}	{{ row.windowDisplay }}	{{ row.services }}	{{ row.reason }}	{{ row.action }}	{{ row.bufferDisplay }}
No conflicts matched the current scope Adjust the conflict scope, buffer, or source rows if you expected overlapping maintenance windows.

Owner	Windows	Conflicts	Critical/High	Conflict minutes	Next conflict	Follow-up	State	Copy
{{ row.owner }}	{{ row.windowCount }}	{{ row.conflictCount }}	{{ row.priorityConflictCount }}	{{ row.conflictMinutesDisplay }}	{{ row.nextConflict }}	{{ row.followUp }}	{{ row.stateLabel }}
No owner brief rows available Owner follow-up appears once at least one parsed maintenance row includes an owner or service context.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Maintenance calendars fail in clusters, not just in single rows. One change may be safe by itself, then become risky when it overlaps a firewall update, storage migration, database failover, or monitoring outage that needs the same owner or touches the same dependency. The calendar view shows time; the review has to decide whether concurrent work is actually compatible.

A maintenance window is a planned period when change work is allowed or expected. A blackout window, often called a freeze window, marks time when normal changes should not be scheduled. Change teams use both to protect customer commitments, high-traffic periods, regulatory events, and staffing plans for monitoring, communication, verification, and rollback.

Time overlap: Two planned windows are active at the same time, even if the shared period is short.
Shared context: The rows share a service, configuration item, dependency, owner, or environment.
Guard time: Extra minutes before or after a window for handoff, verification, cooldown, or rollback readiness.
Blackout hit: A change window touches a freeze period, which usually needs explicit exception handling.

Good conflict review keeps three ideas separate. A clock overlap says the windows intersect. A context match says the overlap is likely to matter. A severity label says how quickly the conflict should be escalated or rescheduled. Same-owner overlaps can create staffing risk even when services differ, while same-dependency overlaps can make rollback unsafe even when different teams own the tickets.

Review quality depends on row quality. Start and end times need one agreed time zone. Services, configuration items, and dependencies need stable names rather than loose text variants. Risk labels should mean the same thing across teams. Status values such as cancelled or rejected should be excluded deliberately, not left mixed with approved work.

Conflict checking cannot replace the change record. Customer promises, exception approvals, staffing constraints, rollback architecture, and business event calendars may not appear in a CSV export. The useful result is a focused list of rows that deserve review before the maintenance night begins.

How to Use This Tool:

Use the checker before a Change Advisory Board review, release train, weekend patch batch, freeze-period exception review, or operations handoff. Start with the smallest schedule slice that supports the decision, then widen it if surrounding changes may compete for the same people or systems.

Paste Maintenance windows as CSV, TSV, pipe-delimited, or semicolon-delimited rows. A header row is optional. Without a header, the column order is ID, start, end, service, owner, environment, CI, dependencies, risk, status, and summary.
Use Browse CSV for a local CSV or text export, Load sample for a known-good schedule shape, or Normalize CSV after parsing to rebuild valid rows into a cleaner table. The Maintenance Conflict Snapshot should move from an input prompt to a window and conflict count after valid dates are present.
Choose Conflict scope. The default catches shared service, CI, dependency, or owner. Service, CI, or dependency only ignores owner-only staffing conflicts. Also flag same environment adds environment matches. Every time overlap shows all adjusted time overlaps.
Set Concurrency threshold to the active-window count your team allows before timeline warnings appear. A threshold of 2 allows two active windows and warns at three or more.
Open Advanced for policy details. Buffer check adds guard minutes before and after each change, Ignored statuses removes statuses such as cancelled or rejected, and Blackout windows adds freeze periods using label, start, end, environment, and optional note.
Fix Review the schedule source notes before relying on the result. Invalid dates, reversed start and end times, ignored rows, blackout parsing problems, threshold clamps, and very long timeline ranges appear there.
Read Conflict Ledger before the chart. It names the two changes or blackout entry, severity, overlap, conflict window, reason, and recommended action. Then use Owner Brief for follow-up ownership and Maintenance Load Timeline for capacity spikes.

If no conflicts appear but the calendar looks crowded, compare the parsed service, CI, dependency, owner, environment, and status values in Window Ledger. Inconsistent naming can hide a real relationship.

Interpreting Results:

Start with critical and high rows. Critical means an actual blackout overlap or an actual overlap where a critical-risk change is involved. High means a high-risk overlap with shared service, CI, dependency, or at least 30 minutes of actual overlap, or a buffer-only hit against a blackout window.

Window Ledger: Confirms parsed rows, duration, normalized risk, status, and missing-owner, missing-environment, or missing-risk issues.
Conflict Ledger: Carries the audit trail for why two rows need review. Check the reason before acting because the same severity can come from shared CI, shared dependency, same owner, blackout policy, or general overlap.
Owner Brief: Groups follow-up by owner and marks each owner as Action needed, Watch, or Clear from the current conflict set.
Maintenance Load Timeline: Shows active windows by time slot and risk label. The threshold line warns only when total active windows are greater than the selected threshold.

A No conflicts snapshot means no valid row pair matched the selected scope after ignored statuses and buffers were applied. It does not prove the maintenance plan is safe. Check spelling, time zone, blackout rows, and dependency fields before using that result as an approval note.

Low and medium rows still have value. A buffer-only near miss may be enough for a handoff note, while a medium same-owner overlap can become a staffing problem if one engineer owns both rollback plans.

Technical Details:

Maintenance conflict detection begins with valid intervals. Each schedule row must have a parseable start time, a parseable end time, and an end later than the start. Rows that fail those checks are excluded from pairwise detection and kept visible as review notes. Optional buffer minutes expand each row for detection, while the displayed actual overlap remains based on the original maintenance windows.

Time overlap is filtered through scope. Under the default scope, an adjusted overlap is reported only when the two rows share service, configuration item, dependency, or owner. Environment-sensitive mode adds same-environment matches, and all-overlaps mode reports every adjusted time overlap even when no shared context was found. Blackout windows are evaluated separately because they carry a stronger policy meaning than ordinary maintenance concurrency.

Formula Core

Adjusted intervals apply guard time to each maintenance window. Actual overlap minutes use the original start and end values, so a buffer-only row can have positive adjusted overlap and zero actual overlap.

AdjustedStart = Start - BufferMinutes

AdjustedEnd = End + BufferMinutes

OverlapMinutes = \max (0, \frac{\min ({End}_{A}, {End}_{B}) - \max ({Start}_{A}, {Start}_{B})}{60000})

If one change runs from 22:00 to 23:30 and another runs from 23:00 to 00:15, the actual overlap is 30 minutes. If one change ends at 22:00, the next starts at 22:10, and the buffer is 15 minutes, the adjusted windows overlap for 20 minutes while the actual overlap remains 0 minutes.

Rule Core

Maintenance conflict scope rules
Conflict scope	Overlap becomes a conflict when	Best fit
Service, CI, dependency, or owner	The pair shares service, CI, dependency token, or owner.	Change Advisory Board screening where technical and staffing conflicts both matter.
Service, CI, or dependency only	The pair shares service, CI, or dependency token.	Technical dependency review that should ignore owner-only staffing overlap.
Also flag same environment	The pair shares service, CI, dependency, owner, or environment.	Production, region, or site calendars where simultaneous same-environment work needs review.
Every time overlap	Any positive adjusted time overlap is shown, with shared reasons retained when present.	Small teams, freeze reviews, or crowded maintenance nights where all concurrency should be visible.

Maintenance conflict severity rules
Severity	Rule	Typical action
Critical	Actual blackout overlap, or actual overlap where either row is critical risk.	Escalate before approval, split a window, or secure explicit risk acceptance.
High	Actual high-risk overlap with shared service, CI, dependency, or at least 30 minutes; buffer-only blackout hits are also high.	Move one change, add owner handoff, or document rollback-safe sequencing.
Medium	Actual overlap with shared service, CI, dependency, same owner, or at least 30 minutes without a higher rule.	Confirm sequencing and monitoring ownership before work begins.
Low	Buffer-only pair conflicts, general schedule overlaps, or lower-risk context overlaps outside the higher rules.	Track as context or review if shared capacity is limited.

Validation and Boundary Rules

Maintenance schedule validation rules
Area	Rule	Interpretation effect
Dates	Start and end must parse as date/time values, and end must be later than start.	Invalid rows are excluded from conflict detection and listed for review.
Status	Statuses listed in Ignored statuses are removed from detection.	Ignored rows stay visible as notes so reviewers can confirm the exclusion.
Risk labels	Critical, high, medium, and low labels include common aliases such as P1, P2, and Sev3.	Unknown risk stays visible and counts with low/unknown rows in the timeline.
Blackout environment	A blank or `all` blackout environment applies globally; otherwise it must match the window environment.	Environment-specific freezes do not affect unrelated environments.
Concurrency threshold	A timeline slot is over threshold only when active windows are greater than the threshold.	A threshold of 2 allows 2 active windows and warns at 3.

Timeline resolution changes with schedule span: short ranges use hourly buckets, wider ranges use 6-hour, daily, or weekly buckets, and very long timelines are capped to keep the chart readable. Pairwise conflict rows remain the audit trail for why specific changes need review.

Limitations and Privacy Notes:

The checker is a schedule-risk aid, not an approval engine. It uses the rows and rules you provide, so it cannot discover undocumented dependencies, exception approvals, customer commitments, staffing limits, or rollback constraints that are missing from the schedule export.

Normalize all rows to one agreed time zone before review. Mixed local times can create false overlaps or hide real ones.
Files are read in the browser and must be under 1 MB. The schedule text is parsed locally by the page rather than sent to a remote conflict service.
Do not paste sensitive production calendars into shared devices or recordings. Redact summaries, host names, configuration item names, and owner names before sharing exports outside the review group.
Blackout rows are only as complete as the policy source you paste. Missing freeze periods will not be inferred from an external calendar.

Worked Examples:

A production payments change from 22:00 to 23:30 and a second payments change from 23:00 to 00:15 share payments-gateway as a dependency. If one row is high risk, Conflict Ledger should show a High conflict with a 30 minute Overlap, a shared-dependency Reason, and a recommendation to move one change or add rollback-safe sequencing.

An operating-system patch ends at 22:00 and a firewall change starts at 22:10 with the same owner. With Buffer check set to 15 minutes, Conflict Ledger shows buffer only for Overlap and a low-severity near miss. Use that row for handoff planning, not as evidence of an actual outage overlap.

A production freeze row in Blackout windows from 00:00 to 06:00 and a database change from 01:30 to 02:15 produce a critical blackout conflict. The Change B value begins with BLACKOUT, the Reason names the blackout environment, and Owner Brief includes follow-up for the change owner.

If a known pair does not appear, compare the Window Ledger values for service, CI, dependencies, owner, environment, risk, and status. A row marked cancelled in Ignored statuses, a misspelled dependency, or a different environment under the selected scope can explain the missing conflict.

FAQ:

What row formats can I paste?

Paste CSV, TSV, pipe-delimited, or semicolon-delimited rows. A header row can use common labels such as change, planned start, owner, service, CI, dependencies, risk, status, and summary.

What time zone does the checker use?

Timestamps are read as local date/time values unless the browser can parse a more explicit timestamp. Normalize exported schedules to one time zone before comparing teams or regions.

Why does the timeline not warn when active windows equal the threshold?

The threshold is a maximum allowed count. The Maintenance Load Timeline warns only when active windows are greater than the Concurrency threshold.

Does a buffer-only conflict mean the changes overlap?

No. It means the guard time around the windows overlaps. Use that row for handoff, monitoring, and rollback planning rather than claiming the original windows overlap.

Why did a row disappear from conflict detection?

Rows with invalid start or end times are excluded, and rows whose status matches Ignored statuses are removed from detection while still being listed in review notes.

Glossary:

Change Advisory Board: A review group that approves, rejects, or requests changes to planned work based on risk, timing, and readiness.
Maintenance window: A planned period when change work is expected or allowed.
Blackout window: A freeze period when normal changes should not be scheduled.
Configuration item: A managed service, host, application, or asset affected by a change.
Dependency: A related service, platform, or system that may be affected by more than one change.
Buffer: Guard time added before and after a window to catch near misses.
Concurrency threshold: The active-window count that marks a timeline slot as overloaded once the count is exceeded.

References:

Change schedules view, ServiceNow, updated March 12, 2026.
Create blackout and maintenance schedules in Change Management, ServiceNow, updated February 1, 2024.
Create, edit, or delete change windows, Atlassian Support.
Schedule maintenance, Atlassian Support.
Master Change Management with Jira Service Management, Atlassian.