We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Standalone reports intermittently show stale data while direct list queries are current

NarasimhaRC
Tera Contributor

Hi Community,

We are investigating an intermittent reporting issue in our Production instance and would appreciate input from anyone who has observed similar behavior.

Issue summary

Direct list views and record forms reflect database updates immediately, but standard reports sometimes continue showing the previous result for approximately 3 to 7 minutes.

This is not limited to one dashboard or report. Multiple teams using unrelated reports and dashboards have reported the same behavior.

Example reproduction

We have a standard report against a task table with a condition similar to:

 
 
 
 
 
Plain Text
 
1 .Closed is empty
 

During a recent reproduction:

  1. A task was open and correctly appeared in the report.
  2. The task was closed at approximately 11:27 AM.
  3. The task form and history immediately showed the task as closed.
  4. A direct table/list query immediately showed the populated Closed value.
  5. The standalone report and the same report embedded in a dashboard continued displaying the task.
  6. We manually refreshed the report several times and also refreshed the entire page.
  7. The task remained in the report until approximately 11:34 AM.
  8. The task then disappeared without any additional update to the record.

The report was therefore temporarily returning or retaining a record that no longer satisfied the report condition.

Scope and observations

What we currently know:

  • The behavior occurs in Production.
  • Direct list queries reflect the latest data immediately.
  • Record forms and history show the committed update immediately.
  • Standalone reports are affected, not only dashboard-embedded reports.
  • Multiple unrelated reports and dashboards are affected.
  • Multiple teams have reported the same general behavior.
  • The issue is intermittent.
  • Reports eventually correct themselves without another record update.
  • Most affected reports have been used for years without this behavior.
  • The first known incident in our environment was reported on April 20, 2026.
  • The behavior was observed before and after our RaptorDB-related changes.
  • The behavior was observed before our Australia release upgrade.

The affected queries are generally straightforward, and the direct list version of the same query is accurate. Therefore, this does not currently appear to be caused solely by an expensive or poorly designed report query.

Current hypothesis

Our leading hypothesis is that something in the report execution path occasionally returns or retains a previously calculated result set.

Possible areas we are considering include:

  • Report-result caching
  • Delayed cache invalidation
  • Application-node-specific cache behavior
  • A difference between list and report execution paths
  • Report refresh not forcing complete query re-execution
  • A reporting-layer or read-consistency issue

We have not confirmed that the database itself is stale. Since direct list queries are current, the delay may be occurring in an intermediate report execution or result-delivery layer.

Questions

  1. Does a classic ServiceNow report query the base table every time it is manually refreshed?
  2. Can classic reports reuse previously calculated result sets or aggregates?
  3. Are there system properties that control classic report-result caching or cache expiration?
  4. Should manually refreshing a report always bypass any cached result?
  5. Can a direct list and a report against the same table use different application or database read paths?
  6. Is there a known report cache or invalidation interval of approximately 3 to 7 minutes?
  7. Has anyone observed similar behavior where the direct list is current but the equivalent report remains stale?
  8. Are there specific logs or debugging options that can identify whether a report response came from cache?
  9. Would a browser HAR trace, correlated with server-side transactions, be the best way to identify the affected layer?

We are planning to capture the following during another reproduction:

  • Task record
  • Direct filtered list
  • Standalone report
  • Dashboard-embedded report
  • Exact encoded queries
  • Record and report sys_ids
  • Closure and refresh timestamps
  • Browser HAR trace
  • Application-node and transaction details, if available

We are intentionally avoiding frequent use of cache.do or speculative global cache-property changes because those actions could affect the entire instance and obscure the root cause.

Has anyone encountered this behavior or identified a related known problem?

Thanks in advance.

Suggested labels

 
1 Reporting
2Dashboards
3Performance Analytics
4Platform Performance
5RaptorDB

Option 2: Concise Community post

Title

Reports intermittently lag 3–7 minutes while direct list queries show current data

Body

Hi Community,

We are seeing an intermittent issue where standard ServiceNow reports display stale data for approximately 3 to 7 minutes, while direct list queries and record forms reflect the same update immediately.

For example, a report contains the condition:

 
 
 
 
 
 
1.Closed is empty
 

A task is closed, and the following occurs:

  • The task form immediately shows the closed state.
  • History shows the closure timestamp.
  • A direct list query immediately shows that Closed is populated.
  • The standalone report still displays the task.
  • Manually refreshing the report and the full page does not immediately remove it.
  • The task eventually disappears from the report without another record update.

This is not isolated to one report or dashboard. Multiple teams using different reports and dashboards have reported similar behavior. Standalone reports are affected as well as dashboard-embedded reports.

Most of these reports have operated normally for years. The first known incident in our environment was reported on April 20, 2026. The behavior also occurred before and after RaptorDB-related changes and before our Australia upgrade.

Our current hypothesis is that the report execution layer occasionally reuses or retains an earlier result. However, report-result caching has not been confirmed.

Has anyone seen similar behavior?

Specifically:

  1. Do classic reports always query the base table when manually refreshed?
  2. Can report results be cached independently from direct list queries?
  3. Are there properties or logs that show report cache hits and invalidation?
  4. Can reports and lists use different read paths or application nodes?
  5. Is there a known three-to-seven-minute reporting cache or refresh interval?

We can reproduce the issue and plan to capture a HAR trace with exact timestamps for server-side correlation.

Thanks!

0 REPLIES 0