Maintenance Conflict Snapshot
{{ summaryPrimary }}
{{ summaryLine }}
{{ 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' }}
Header is optional. Default order is id, start, end, service, owner, environment, CI, dependencies, risk, status, summary.
{{ sourceStatus || sourceHint }}
Use the default for CAB checks where owner, CI, service, or dependency overlap matters.
Set the review threshold for simultaneous approved changes.
windows
Use 0 for exact overlaps, or add handoff and rollback guard time.
min
Leave blank to evaluate every valid row.
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 }}
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.
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 }} 

          

        

      

    

  

                

                

                    

                        

                            Tags: Devops, Diagnostics, Sysadmin
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    

    
Maintenance-window conflict checking turns a change calendar into a review queue. It looks for planned work that overlaps in time, then asks whether those overlapping changes share a service, configuration item, dependency, owner, environment, or blackout period that could raise operational risk.


    
This matters most before a Change Advisory Board review, weekend patch batch, release train, or infrastructure freeze. Two changes can look harmless when each ticket is read alone, but the combination can overload the same team, touch the same dependency, or remove the rollback margin that a high-risk change needs. A compact conflict ledger gives reviewers a faster way to decide which change should move, which owner needs a handoff, and which overlap only needs a note.


    

      

        

          

            
Schedule rows

            
Change ID, start, end, service, owner, CI, dependencies, risk, and status

          

        

        

          

            
Overlap rules

            
Scope, buffer minutes, ignored statuses, and blackout periods

          

        

        

          

            
Review outputs

            
Window ledger, conflict ledger, owner brief, timeline, and JSON record

          

        

      

    


    
The tool works with pasted CSV, TSV, pipe-delimited, or semicolon-delimited rows. A header is optional, and the default column order follows common change exports: ID, start, end, service, owner, environment, CI, dependencies, risk, status, and summary. File browsing and drag-and-drop read plain text locally, while the normalize action rebuilds valid rows into canonical CSV for cleaner handoff.


    
Treat the result as a schedule-risk aid, not as approval by itself. It does not know every hidden dependency, staffing constraint, monitoring plan, or rollback condition. It helps surface overlaps that deserve human review before a change is approved or copied into a wider maintenance plan.

  






  

    
Technical Details:


    
The checker first parses usable schedule rows and drops blank lines plus comment lines that start with #. It detects the row delimiter from the first non-empty line, maps recognized headers when a header is present, and falls back to the default column order when the source has no header. Start and end values are read as local date/time values, so a schedule collected from several regions should be normalized to one agreed time zone before review.


    
A maintenance window is valid only when both timestamps parse and the end is after the start. Rows with ignored statuses are removed from conflict detection and listed in validation notes. Missing owner, missing environment, and unknown risk do not block the row, but they appear as row issues in the window ledger so the reviewer can repair the source or assign follow-up.


    
Conflict Rule Core:

    

      

        
        
          

            Scope setting
            Overlap becomes a conflict when
            Best use
          

        
        
          

            Service, CI, dependency, or owner
            The pair shares a service, CI, dependency, or owner.
            Default CAB screening where team load and shared components both matter.
          

          

            Service, CI, or dependency only
            The pair shares a service, CI, or dependency.
            Technical dependency checks that should ignore owner overlap.
          

          

            Also flag same environment
            The pair shares service, CI, dependency, owner, or environment.
            Production, region, or site calendars where same-environment load needs review.
          

          

            Every time overlap
            Any two valid windows overlap in time, even without shared metadata.
            Small teams or freeze reviews where all simultaneous work should be visible.
          

        
      

    


    
Buffer minutes expand each change before the overlap check. A zero-minute buffer reports only direct time overlap. A positive buffer also catches near misses, such as one change ending five minutes before another begins. Buffer-only conflicts are labeled separately in the conflict ledger so guard-time issues do not look like direct implementation overlap.


    
Severity Rules:

    

      

        
        
          

            Condition
            Severity
            Recommended reading
          

        
        
          

            Direct blackout overlap, blackout reason, or a critical-risk change in the pair
            Critical
            Escalate before approval, split the work, or document explicit risk acceptance.
          

          

            High-risk pair with shared service, CI, dependency, or at least 30 minutes of direct overlap
            High
            Move one change, add a handoff, or define a rollback-safe sequence.
          

          

            Same service, same CI, shared dependency, same owner, or at least 30 minutes of direct overlap
            Medium
            Confirm sequencing, monitoring ownership, and capacity before the window starts.
          

          

            Buffer-only pair overlap or low-risk context overlap
            Low
            Keep the context visible, especially when guard time is part of the runbook.
          

        
      

    


    
Risk labels are normalized from common values such as critical, sev1, p1, high, medium, and low. Unrecognized risk stays valid but is treated as unknown for the window ledger and low-risk timeline count. Dependencies are split on common separators, then compared as normalized tokens.


    
Blackout rows use label,start,end,environment,note. A blank environment or all applies globally; otherwise the blackout applies only to matching maintenance-window environments. Blackout conflicts use CAB as the second owner in the owner brief, which makes freeze-period follow-up visible beside team-owned conflicts.

  






  

    
Everyday Use & Decision Guide:


    
Start with the export that change reviewers already trust. If your source system uses different column names, keep the header row so service, owner, CI, dependencies, risk, and status are mapped correctly. If there is no header, arrange the columns in the default order shown in the input help before pasting.


    
Use the default conflict scope for a first review. It catches the common operational problems: the same service is being changed twice, the same CI or dependency is touched by two teams, or one owner is carrying too much simultaneous work. Switch to technical-only scope when team overlap creates noise. Switch to environment-sensitive scope when production or regional concurrency is the real concern.


    
    
      
  • Set Concurrency threshold to the maximum number of simultaneous windows your team is willing to review as normal load.
    • 
      
  • Use Buffer check when handoff, rollback, monitoring, or communication needs time between changes.
    • 
      
  • Add Ignored statuses for cancelled, rejected, or draft states only when those rows should not affect approval.
    • 
      
  • Add blackout rows for freeze periods, business events, vendor embargoes, or staff-coverage gaps that should block or escalate work.
    • 
      
  • Use Normalize CSV after parsing a messy export so the reviewed source can be copied back into a ticket or shared with another reviewer.
    • 
    


    
The best review path is summary first, conflict ledger second, owner brief third. The summary tells you whether any critical or high conflicts exist. The conflict ledger names the pair, shared reason, overlap duration, and action language. The owner brief turns the same data into team follow-up so one person can see their pending conflicts without scanning every row.


    
The calculation runs in the browser. Pasted rows and browsed files are not sent to a scheduling service for conflict detection. Still, schedule rows can contain internal change IDs, system names, customer details, and security-sensitive timing, so treat copied CSV, DOCX exports, JSON, chart images, and shareable page state as operational evidence.

  






  

    
Step-by-Step Guide:


    
    
      
  1. Paste schedule rows into Maintenance windows, browse for a small CSV/TXT export, drop a file on the textarea, or load the sample to inspect the expected shape.
    2. 
      
  2. Confirm that the summary badge shows the expected number of valid windows. If validation notes appear, fix invalid start/end values, ignored statuses, or blackout date errors first.
    3. 
      
  3. Choose Conflict scope based on the review question: dependency risk, team load, environment load, or every simultaneous change.
    4. 
      
  4. Set Concurrency threshold for the load timeline. Buckets over the threshold are reported as validation notes.
    5. 
      
  5. Open Advanced when the review needs guard time, ignored statuses, or blackout windows. Keep buffer at 0 for exact overlap detection.
    6. 
      
  6. Open Window Ledger to verify parsed rows, risk labels, missing owner/environment notes, CI values, dependencies, and statuses.
    7. 
      
  7. Open Conflict Ledger to review pairs by severity, direct or buffer overlap, reason, and recommended action.
    8. 
      
  8. Open Owner Brief to route follow-up by owner, priority conflict count, next conflict time, and state.
    9. 
      
  9. Use the timeline and exports only after the ledgers match the source calendar you intended to review.
    10. 
    

  






  

    
Interpreting Results:


    
No conflicts means no valid rows matched the current overlap and scope rules. It does not prove the maintenance plan is safe. The result can change when hidden dependencies are added, statuses are included, blackout rows are pasted, buffer minutes are raised, or a broader scope is selected.


    

      

        
        
          

            Result area
            What to read
            Common mistake
          

        
        
          

            Window Ledger
            Parsed start/end, duration, service, owner, environment, CI, dependencies, risk, status, summary, and row issues.
            Acting on conflicts before confirming that the source columns mapped correctly.
          

          

            Conflict Ledger
            Change pair, severity, direct or buffer overlap, conflict window, shared reason, and action.
            Treating buffer-only overlap as a direct implementation collision.
          

          

            Owner Brief
            Owner-level windows, conflict counts, critical/high count, conflict minutes, next conflict, and follow-up.
            Assuming owner load is clear when a shared CI or dependency still has conflicts.
          

          

            Maintenance Load Timeline
            Active-window count by bucket, stacked by risk, with a threshold marker.
            Reading bucket load as exact minute-by-minute concurrency across long schedule ranges.
          

          

            JSON
            Structured settings, summary, windows, conflicts, owners, timeline rows, and validation messages.
            Sharing the record without checking for sensitive change details.
          

        
      

    


    
The timeline buckets scale with the schedule span: hourly for short ranges, then wider buckets for longer schedules, with a cap to keep the chart readable. Use it to spot loaded periods and threshold breaches, then return to the conflict ledger for exact pair-level timing.


    
Critical and high counts deserve the fastest review, but lower-severity findings can still matter when they affect a fragile service, an understaffed shift, a long rollback path, or a customer-visible event. Use severity to sort the queue, then apply the real change policy before approving or moving work.

  






  

    
Worked Examples:


    
Example 1: Shared payment dependency

    
The sample includes CHG-1001 for a payments edge patch and CHG-1002 for a firewall policy update. Their times overlap from 2026-05-10 23:00 to 2026-05-10 23:30, and both reference the payments gateway dependency. Because one row is critical risk, the conflict ledger places the pair in the critical queue and recommends escalation before approval.


    
Example 2: Production storage and backup overlap

    
CHG-1003 touches storage from 01:00 to 02:20, while CHG-1005 touches backup from 01:30 to 03:00. They share the storage and backup relationship through dependencies, so the conflict ledger calls out the overlap even though the services are named differently. The owner brief also gives Infra follow-up because the same owner carries both windows.


    
Example 3: Buffer-only guard-time conflict

    
If one change ends at 22:00 and another begins at 22:10, a zero-minute buffer reports no direct overlap. Setting Buffer check to 15 minutes creates a buffer-only finding if the scope rules match. That finding is useful when monitoring handoff or rollback preparation needs a clear gap between changes.


    
Example 4: Blackout period catches an otherwise clean row

    
A blackout row such as Holiday freeze,2026-05-11 00:00,2026-05-11 06:00,prod,CAB freeze applies to production windows during that period. A production maintenance row that overlaps it is listed as a blackout conflict, with CAB included in owner follow-up. A staging row during the same period is not flagged by that blackout unless the blackout environment is blank or all.

  






  

    
FAQ:


    

      Does the checker require a header row?
      
No. A header row is helpful when the source uses named columns, but headerless input works when the columns follow the default order shown in the input help.

    


    

      Why did a row with a cancelled status disappear from conflicts?
      
Rows whose status matches Ignored statuses are removed from conflict detection and listed in validation notes. Clear that field or remove the status from the ignore list if cancelled or rejected rows should still be visible.

    


    

      Why did two rows overlap in time but not appear in the conflict ledger?
      
The selected scope may require a shared service, CI, dependency, owner, or environment. Choose Every time overlap when every simultaneous window should be reported.

    


    

      How are time zones handled?
      
Entered timestamps are parsed as local date/time values for display and comparison. Normalize exports to one agreed time zone before pasting rows from several regions or systems.

    


    

      Are maintenance schedule details uploaded for checking?
      
The parsing and conflict checks run in the browser. Be careful with exported files, copied tables, JSON, chart images, and page links because those can still expose internal schedule details.

    

  






  

    
Glossary:


    

      
Maintenance window

      
An approved period for planned operational work that may affect a service, device, platform, or customer path.

      
Blackout window

      
A freeze period when planned changes should be blocked or escalated because timing risk is too high.

      
Configuration item

      
The service, device, host, component, or asset that a change touches.

      
Shared dependency

      
A named upstream, downstream, platform, or infrastructure element used by more than one planned change.

      
Buffer-only conflict

      
A near miss created by guard time around two windows, without direct time overlap between the original start and end values.

      
Concurrency threshold

      
The active-window count used to warn when too many maintenance windows are running in the same timeline bucket.

      
Owner brief

      
A summary that groups windows and conflicts by owner so follow-up can be routed quickly.

    

  






  

    
References: