Change blackout windows prevent changes from being scheduled during critical periods like holidays, quarter-end freezes, or major system maintenance. You'll build a schedule exception and configure the enforcement mechanism that works for your change process.
Why change blackouts exist
Without blackout windows, change coordinators spend their time manually rejecting changes that land during critical periods. They're constantly playing defense — catching holiday deployments, quarter-end changes that could affect financial systems, or overlapping maintenance windows that could cascade into outages. Change managers and CAB members end up as the human firewall, which doesn't scale and misses things when people are out of office or distracted.
How blackout windows work
A blackout window is a schedule exception that defines when changes shouldn't be scheduled. But ServiceNow doesn't automatically enforce these — that's a common misconception. You create the schedule exception first, then build the enforcement layer through Business Rule conditions, CAB workbench configuration, or approval workflows. The schedule exception is just the calendar; the enforcement is what actually blocks the changes. Most teams start with a simple date range exception and add Business Rule enforcement, then layer in type-specific blackouts and CAB workbench integration as their change process matures.
Beyond basic blackouts
Production blackout implementations go beyond single date ranges. You'll want recurring blackouts for predictable periods (month-end, quarter-end), type-specific exceptions (emergency changes bypass blackouts, standard changes have different windows), and integration with your CAB approval process. Advanced setups include automated notifications when changes are blocked, grace periods for changes already in progress, and different blackout rules for different CI types or business services.
Before you start
- •change_manager role or admin role
- •Access to Change > Administration menu
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the schedule exception
Navigate to Change > Administration > Schedules and open your change schedule (usually 'Change Schedule' or '24x7'). Click New in the Schedule Exceptions related list. Set the Name to something descriptive like 'Q4 Financial Freeze 2024'. Set Type to 'Blackout' and configure your start/end dates and times.
Use consistent naming conventions — include the year and specific period so you can easily identify old blackouts to clean up later.
Configure the time window
Set Start date and End date to bracket your blackout period. If this is an all-day blackout, set Start time to 00:00:00 and End time to 23:59:59. For partial-day blackouts, set the specific hours. Check All day if appropriate, but be aware this uses the schedule's time zone, not the user's time zone.
Set blackout scope and repeat
If this blackout should repeat (like month-end freezes), configure the Repeat type and Repeat until fields. For one-time events, leave Repeat type empty. In the Description field, document what types of changes this blackout affects — this helps when people ask why their change was blocked.
Build the enforcement Business Rule
Navigate to System Definition > Business Rules and create a new rule on the Change Request table. Set When to 'before' and check Insert and Update. In the Condition field, add a script that checks if the planned start date falls within your blackout window using the schedule API. Use gs.getSchedule().isInSchedule() to validate against your schedule exceptions.
Configure conditional enforcement
In your Business Rule condition, add logic to handle different change types. Emergency changes might bypass blackouts entirely, while standard and normal changes get blocked. Check the change type field and risk level before applying blackout rules. Set gs.addErrorMessage() to provide clear feedback about why the change was blocked and when the blackout ends.
Test the blackout enforcement
Create a test change request with a planned start date that falls within your blackout window. Verify the Business Rule fires and blocks the change with an appropriate error message. Test with different change types to ensure your conditional logic works. Try updating an existing change to move it into the blackout period.
Enable CAB workbench integration
If you use the CAB workbench, navigate to Change > CAB Workbench > Administration and check your blackout schedule configuration. The workbench can highlight changes that conflict with blackout windows and provide bulk actions to reschedule them. Configure the schedule reference to point to your change schedule with the blackout exceptions.
Best practices
Always include exception logic for emergency changes — when production is down, blackout windows shouldn't prevent fixes.
Set clear error messages that tell users when the blackout ends and suggest alternative dates — 'blocked by policy' messages create help desk tickets.
Build conditional enforcement based on change type and risk level rather than blanket blocking all changes — different change types need different rules.
Document blackout periods in advance and communicate them to change requestors — surprise blackouts create friction with development teams.
Use recurring schedule exceptions for predictable blackouts like month-end or quarter-end rather than manually creating them each time.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue