Reporting on sys_audit

[andrewcobbold]

Why Reporting on the sys_audit Table in ServiceNow Can Be Frustrating

If you’ve ever tried to build a report on the sys_audit table in ServiceNow, you’ve probably run into performance headaches pretty quickly. On paper, it’s a goldmine with every field change, every update, all neatly captured for audit and compliance. But in reality, reporting on it can feel like pushing the platform a bit too far.

The main issue is scale. In most enterprise environments, sys_audit grows fast and becomes one of the largest tables in the system. Standard reports aren’t really designed to handle that kind of volume efficiently, especially when you start layering filters like date ranges, field names, or specific records. It’s not uncommon for reports to run slowly or, worse, just timeout completely.

Another challenge is how the data is structured. Useful filters like documentkey, fieldname, or value changes don’t always benefit from strong indexing, so queries can end up scanning a huge amount of data behind the scenes.

A simple workaround I’ve found effective is to skip the reporting engine altogether and use a direct URL query instead. By building an encoded query string in the URL, you can hit the table more directly and get results much faster.

For example:

/sys_audit_list.do?sysparm_query=tablename=incident^fieldname=state^sys_created_on>=javascript:gs.daysAgoStart(7)

This approach isn’t meant to replace formal reporting, but for quick analysis or troubleshooting, it works really well. It’s one of those practical tricks that can save you a lot of time and frustration when working with large audit datasets.