Managing ServiceNow Storage Effectively: Tips, Pitfalls, and AI Opportunities

Introduction

As organizations grow, so does their ServiceNow data. From audit logs to attachments and historical records, an unmanaged instance can quickly exceed storage limits — leading to performance degradation, license breaches, or even functionality risks.

Storage management isn't a static problem either. Two things keep reshaping it: cloning activity that spikes logs and errors in ways that catch teams off guard, and newer platform capabilities — AI Search, Now Assist, AI Agents — that introduce entirely new categories of storage consumption nobody was tracking a couple of years ago. This article covers the fundamentals, corrects a couple of mechanics that are easy to get wrong, and then covers both of those newer wrinkles directly.

1. Understand What's Consuming Space

Start by identifying top storage consumers:

• Navigate to Instance Usage > Application Usage Overview for the officially reported Primary DB size and top-level breakdown.
• Focus on heavy tables like sys_audit, sys_email, sys_attachment, task, and cmdb_ci.

A word of caution before reaching for a script here: ServiceNow restricts direct SQL access to instances for security reasons, so there isn't a built-in scriptable API that hands back exact per-table byte sizes the way a database admin tool would. If you need an approximation from script rather than the UI, the approach below samples a limited number of records and estimates from there — it's directional, not exact, and gets slower and less representative the larger the table is.

function estimateTableSize(tableName, sampleLimit) {
    var gr = new GlideRecord(tableName);
    gr.setLimit(sampleLimit || 10000);
    gr.query();

    var totalBytes = 0;
    var count = 0;
    while (gr.next()) {
        for (var field in gr) {
            totalBytes += gr[field].toString().length;
        }
        count++;
    }
    gs.print(tableName + ': sampled ' + count + ' records, ~' + (totalBytes / 1048576).toFixed(2) + ' MB in sample');
}

estimateTableSize('incident', 10000);

For an authoritative figure on very large tables, ServiceNow Support can provide an official database footprint report through the Now Support portal — worth requesting directly rather than relying on script-based estimates when the exact number actually matters (for license or capacity conversations, for instance).

2. Use Table Cleaner (Auto Flush) for Log and System Tables

For fast-growing system tables, Table Cleaner — the underlying mechanism behind what's commonly called "Auto Flush" — is the recommended method to manage data safely and efficiently, without hand-rolled deletion scripts.

Examples of flushable tables:

• syslog_transaction
• syslog
• sys_email
• sys_audit_delete
• ecc_queue

Configure via: Navigate to System Maintenance > Table Cleanup (these records are labeled "Auto Flushes"), or type sys_auto_flush_list.do directly into the Navigator filter.

Example: Auto-flush syslog_transaction older than 30 days

The actual fields on an Auto Flush record are Matchfield (the date/time field to check) and Age in seconds (a plain numeric value, not a script) — not a scripted condition or batch size field:

Table: syslog_transaction
Matchfield: sys_created_on
Age in seconds: 2592000

A few things worth knowing before relying on this:

• The scheduled job that actually runs Table Cleaner (BulkTableCleaner) runs once per hour by default — don't expect near-real-time cleanup.
• Table Cleaner skips tables subject to table rotation or table extension — for tables like sysevent and syslog on newer instances, rotation may already be handling this instead, so check which mechanism is actually active before assuming Auto Flush is doing the work.
• Some default Auto Flush records exist for important reasons and shouldn't be casually deactivated. ServiceNow Support has specifically warned against deactivating the default record for workflow context cleanup, for example — doing so can let wf_context/wf_history grow unmanageably large. Understand what a default record is protecting against before turning it off.

✅ Auto-flush avoids scripting risks and runs in a controlled, platform-managed background process — a real advantage over ad hoc deletion scripts.

3. Use Retention Policies for Business Data

For structured business records (like incidents or change requests), use:

• Auto Archive Rules for historical visibility.
• Auto Delete Rules for permanent cleanup when archiving isn't required.
• Data Retention Policies aligned with legal/compliance frameworks.

Avoid deleting directly via script unless absolutely necessary.

4. AI-Driven Optimization (Emerging Practice)

AI models can enhance storage strategies by:

• Recommending purge targets based on usage frequency.
• Highlighting duplicate or redundant attachments.
• Surfacing patterns in job performance that would take much longer to spot manually.

Treat this as a direction to explore rather than a copy-paste script — the exact fields available for tracking job execution duration can vary by release and job type, so verify against your own instance's schema before building automation around a specific field name.

5. Post-Clone Storage Spikes: A Different Kind of Problem

This deserves its own section because it's a genuinely different failure mode than steady organic growth — it's a sudden spike triggered by an operational event, and it catches teams off guard specifically because it wasn't there yesterday.

Why clones spike storage and logs:

• Reactivated integrations pointing at endpoints that no longer make sense in that environment. A clone brings over business rules, REST Message configurations, and scheduled jobs exactly as they existed in production — including ones that were deliberately disabled in the lower environment before the clone. If those integrations fire against production third-party endpoints from a non-prod instance (or simply fail because the target system, credentials, or network path isn't valid there), each failed attempt can generate its own error log entry, retry, and failure record. Run repeatedly on a schedule, this adds up fast.
• Scheduled jobs resuming their original cadence. If job schedules were deliberately staggered or narrowed in scope in a lower environment before the clone (to avoid overloading a shared third-party source, for instance), a clone resets that back to the production schedule and scope by default — meaning full-volume pulls can resume running on a lower environment that was never sized or intended to handle that load, generating a correspondingly large volume of new records and log entries.
• A burst of platform-level log activity from the clone process itself — plugin activation/reconciliation, table structure changes, and general clone housekeeping generate their own log volume in the days immediately following a clone, separate from anything integration-related.

What actually helps:

• Don't rely on manually re-disabling or re-scoping integrations after every clone — that's the same recurring-toil problem covered in depth in this blog's integration best practices coverage on Preserver List & Cloning. The durable fix is the same one: gate environment-sensitive behavior behind a system property that's explicitly excluded from being overwritten by clone, so a lower environment stays safely configured through every future clone automatically, rather than depending on someone remembering to redo it.
• Budget for a post-clone storage and log review as a standing checklist item, not an ad hoc reaction. Check sys_email, syslog, and ecc_queue specifically in the days following a clone — these are usually where a failing reactivated integration shows up first and most visibly.
• If a lower environment consistently spikes after every clone for the same reason, that's a signal the underlying integration's environment-awareness needs fixing at the configuration level — not something to keep manually cleaning up after each time.

6. Newer Storage Consumers: AI and Beyond

Traditional "top tables" checklists were built around a platform that didn't have to account for what's now a real and growing category: AI-related data. As Now Assist, AI Search, and AI Agent capabilities have become more embedded in the platform, they've introduced storage consumption patterns that don't show up on an older list of "usual suspects":

• AI Search indexing and embeddings — powering semantic search consumes storage in ways fundamentally different from traditional keyword-indexed data, and it scales with the content being indexed, not just with transactional record volume.
• Now Assist interaction and session data — conversational AI interactions, summaries, and generated content can accumulate meaningfully over time, especially at higher adoption.
• AI Agent execution history and traces — as agentic automation takes on more multi-step orchestration work, the execution trail it leaves behind is itself a new, growing data category.

Two practical takeaways:

• Check whether your instance's Application Usage Overview breaks out AI-related consumption separately. ServiceNow has been building AI-specific usage visibility into its standard reporting as these features have matured — that's a more reliable starting point than trying to guess which underlying tables to watch, since the exact schema for these newer capabilities shifts release to release.
• Don't assume your existing retention and Auto Flush strategy automatically covers these new categories. A cleanup strategy built entirely around sys_audit, sys_email, and sys_attachment won't necessarily catch a newer AI feature's storage growth unless someone deliberately extends the review to include it. Treat "are we covering the newer AI-related tables too" as a standing question during periodic storage reviews, not a one-time addition.

7. Common Pitfalls to Avoid

• Overusing scripting to delete data: Prefer system-supported methods like Table Cleaner or retention rules.
• Archiving ≠ deleting: Archives still consume space, though less than active records.
• Uncoordinated full data pulls from PROD can lead to slowness, API throttling, or job failures.
• Neglecting email and attachment tables, which silently grow large.

Script: Find attachments over 50MB, older than 1 year

var attach = new GlideRecord('sys_attachment');
attach.addEncodedQuery('size_bytes>52428800^sys_created_onRELATIVELE@year@ago@1');
attach.query();
while (attach.next()) {
  gs.print(attach.file_name + " — " + (attach.size_bytes / 1048576).toFixed(2) + " MB");
}

8. Enforce Limits for Integrations and APIs

• Confirm your instance's REST query record-limit properties in System Properties (property names can vary somewhat by release — check your specific instance's REST-related properties rather than assuming a fixed name applies across all versions) to cap how much a single API response can return.
• Restrict external integrations from triggering large, unbounded table queries.
• Rate-limit ETL tools, or coordinate with those teams directly on full versus delta pull practices.

9. Collaborate with Data Consumers

• Communicate with data warehouse/ETL teams using the Table API.
• Insist that full-load testing happens in non-prod, never directly against production.
• Prevent ad hoc, unattended test queries from running against live instances.

System Tables to Auto-Flush or Archive

Table Name	Reason for Growth	Recommended Action
sys_audit	Field change logs	Auto-archive or delete per retention policy
sys_email	All email activity	Auto-flush after retention window
syslog_transaction	Transaction logs	Auto-flush older entries
sys_audit_delete	Deletion audit records	Auto-flush per retention policy
sys_attachment_doc	File storage (binary content)	Identify and purge large/old attachments
ecc_queue	Integration/MID Server traffic, including reactivated post-clone jobs	Auto-flush, and review closely after every clone

Conclusion

Managing storage in ServiceNow is about more than just saving disk space. It's a proactive approach to maintaining performance, cost efficiency, and platform health. With the right mix of Table Cleaner (Auto Flush), retention rules, and AI-enhanced analysis, you can keep your instance lean and compliant — while avoiding manual, error-prone deletion methods.

Two things are worth carrying forward beyond the basics: storage problems aren't only steady organic growth — clone events create their own sharp, predictable spikes that deserve a standing checklist item, not a surprised reaction. And the definition of "what's consuming space" keeps expanding as the platform does — AI-related data is a real, growing category that an older storage strategy won't automatically account for. Building both into a periodic review, rather than treating storage management as a one-time setup, is what keeps this from becoming a recurring fire drill.