When you make configuration changes and users still see old behavior, ServiceNow is serving cached versions of your updates. This guide shows you how to flush the cache properly without causing unnecessary performance hits.
Why cached configuration causes problems
ServiceNow aggressively caches configuration — ACLs, UI policies, business rules, client scripts, and form layouts — to keep the platform fast. When you update an ACL or change a UI policy, the old version stays in memory until the cache expires naturally (usually 15-30 minutes) or gets flushed manually. Users keep seeing the old behavior, admins think their changes didn't work, and you waste time debugging configuration that's actually correct. Platform admins and developers hit this constantly, especially when testing security changes or form behavior.
How ServiceNow cache flushing works
ServiceNow has two cache levels: node-level (affects one application server) and cluster-level (affects all nodes in your instance). The cache.do page lets you flush both, but they behave differently. A node flush only clears the server you're connected to — fine for development, useless in production with load balancers. A cluster flush hits all nodes but causes brief performance degradation as every server rebuilds its cache simultaneously. Most configuration changes need cluster-level flushing: ACLs, UI policies, client scripts, business rules, and anything that affects the user interface.
When and how to flush safely
In development instances, flush liberally — performance doesn't matter and you need to see changes immediately. In production, cluster flushes should be planned. They cause 10-30 seconds of slower response times as the cache rebuilds, so avoid them during peak usage. Some changes don't need cache flushes at all: workflow activities, scheduled job configurations, and most application data. The key is understanding what ServiceNow caches versus what it reads fresh from the database every time.
Before you start
- •admin role or cache_flush_admin role
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
Navigate to the cache management page
Type 'cache.do' in the application navigator filter or add it to your instance URL: https://yourinstance.service-now.com/cache.do. This bypasses the normal menu system and takes you directly to the cache management interface.
Bookmark this URL — you'll use it frequently during development and testing phases.
Choose your flush scope
Look at the two main options: 'Flush cache on this node' and 'Flush cache on all nodes'. For development instances or when you're the only user, use 'this node'. For production or shared instances where users might be on different application servers, use 'all nodes'.
When in doubt, use 'all nodes' — it's better to have brief slowness than users still seeing cached behavior.
Select specific cache types
Expand the cache type options if you want to flush selectively. The most commonly needed are: 'Access Control' (for ACL changes), 'UI Policy' (for form behavior changes), 'Client Script' (for client-side code changes), and 'Business Rule' (for server-side logic changes). Leave 'All' selected unless you specifically want to preserve certain cached data.
Selective flushing causes less performance impact, but 'All' is safer when you're unsure what needs clearing.
Execute the cache flush
Click the flush button for your chosen scope. The page will reload and show a confirmation message. In production environments, expect 10-30 seconds of slower system response as ServiceNow rebuilds the cache across all nodes.
Don't flush multiple times rapidly — each flush makes the performance impact worse.
Verify the changes took effect
Navigate to where users were experiencing the old behavior and test your changes. If you flushed ACLs, check that fields show/hide correctly. If you flushed UI policies, verify form behavior matches your configuration. Clear your browser cache too — sometimes the issue is client-side caching, not server-side.
Test in an incognito/private browser window to rule out browser-level caching issues.
Best practices
Never flush cache in production during peak business hours — the performance impact affects all users simultaneously.
Use selective cache flushing when possible rather than 'All' — flushing only ACL cache for security changes is faster than clearing everything.
Set up a cache_flush_admin role for developers instead of giving them full admin — they can clear cache without other administrative privileges.
Document which changes require cache flushes for your team — new developers often forget and spend hours debugging 'broken' configuration.
After major configuration deployments, schedule a cluster cache flush as part of your release process rather than waiting for user complaints.
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