Resolved incidents pile up without automatic closure, cluttering your active incident count and making reporting unreliable. This guide walks you through configuring ServiceNow to automatically close resolved incidents after a specified number of days.
Why incidents need auto-close
Without auto-close, incidents sit in Resolved state indefinitely. This inflates your active incident counts, skews SLA metrics, and gives stakeholders an unclear picture of what's actually open. Service desk teams — the ones who manage these incidents daily — end up manually closing hundreds of resolved incidents or just living with inaccurate numbers. The worse your incident hygiene gets, the less trust people have in your reporting.
How auto-close works
ServiceNow uses a simple two-part system: a system property defines how many days to wait after resolution, and a scheduled job runs daily to transition qualifying incidents from Resolved to Closed. The job checks the resolved_at timestamp, compares it to your configured wait period, and updates the state. You can customize the notification users receive when their incidents auto-close, and you control whether new comments reopen closed incidents.
Production improvements
Once basic auto-close works, consider customizing the wait period by category or priority — P1 incidents might auto-close after 3 days while P4s wait 7 days. You can modify the scheduled job to exclude certain assignment groups or add business rules that prevent auto-close for incidents with pending tasks. The notification template is also worth customizing to include closure codes or satisfaction survey links.
Before you start
- •admin role or incident_manager role
- •Email notifications configured and working
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
Set the auto-close wait period
Navigate to System Properties > System Properties and search for 'glide.incident.auto_close_days'. If the property doesn't exist, create it by clicking New. Set the value to your desired number of days — most organizations use 7. This controls how long ServiceNow waits after an incident reaches Resolved state before auto-closing it.
Start with 7 days — it's long enough for users to object if something was resolved incorrectly, but short enough to keep your numbers clean.
Verify the scheduled job exists
Go to System Scheduler > Scheduled Jobs and search for 'Close Resolved Incidents'. This job should already exist in your instance. Check that it's Active and runs daily. If it doesn't exist, create it with name 'Close Resolved Incidents', set it to run daily, and use the script: 'new IncidentUtils().closeResolvedIncidents();'.
Configure comment reopening behavior
Navigate to System Properties > System Properties and search for 'glide.incident.reopen_on_comment'. Set this to 'true' if you want new comments on closed incidents to reopen them automatically, or 'false' to prevent reopening. Most organizations set this to 'true' so users can reopen incidents by adding comments if the closure was premature.
Test the auto-close functionality
Create a test incident, resolve it, then manually update its Resolved field to a date older than your configured wait period. Navigate to System Scheduler > Scheduled Jobs, find 'Close Resolved Incidents', and click Execute Now. Check that your test incident moved to Closed state and verify the closure notification was sent.
Customize the auto-close notification
Go to System Notification > Email > Notifications and search for 'Incident Auto Close' or create a new notification. Set the Table to 'Incident [incident]', When to 'Updated', and add a condition for 'State changes to Closed'. Customize the Subject and Message body to include relevant incident details. Add the incident opener and any relevant assignment groups to the Recipients.
Monitor and adjust timing
Run the scheduled job manually a few times over the next week to see how many incidents it closes and whether users complain about premature closures. If you're getting pushback, increase the wait period in glide.incident.auto_close_days. If resolved incidents are piling up too long, decrease it.
Best practices
Set different auto-close periods for different priorities using a custom business rule instead of the system property if your organization needs that granularity.
Always include incident details like number, short description, and resolution notes in your auto-close notification — users need context about what's being closed.
Monitor the scheduled job execution history regularly to catch failures early — if it stops running, resolved incidents accumulate quickly.
Don't set the auto-close period below 3 days unless your service desk is exceptionally responsive — users need time to validate that their issues are truly resolved.
Consider excluding incidents with pending tasks or approvals from auto-close by customizing the scheduled job script.
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