Excessive Repetitive Warning Messages in System Log - Support and Troubleshooting

Excessive Repetitive Warning Messages in System Log Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The System Logs tables (commonly syslog or related logging tables) experience a significant buildup of repetitive warning- or info-level entries. A large volume of similar records is generated daily — often emitted by a single platform component, integration, or rendering pattern — resulting in a bloated log table and reduced log usability.

Field Value Affected Surface System Logs → All / Warnings / Transactions module, and any downstream report or dashboard reading from the syslog family of tables Trigger A platform component, scheduled job, integration, or UI behaviour emits the same (or pattern-matching) log line at high frequency Customer Impact Log table bloat Reduced log signal-to-noise — genuine errors become harder to spot, and storage / index growth accelerates Scope : This article describes the generic mechanism for suppressing repetitive log entries. The same approach applies to any noisy log line that matches a stable, identifiable text pattern — regardless of the originating component or the specific message text. Symptoms .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Observed Behaviour One or more repetitive log lines dominate the System Logs view, often with the same source, level, and near-identical message text The syslog table grows noticeably faster than baseline — daily row counts increase by significantly over a short window Filtering or searching the log table becomes slow or unwieldy because the result set is saturated by the noisy lines Genuine errors and warnings are buried under the noise, making operational triage and root-cause analysis harder The repetitive line is typically informational or warning-level, not error-level — meaning no actual failure is occurring, just routine emission at high volume What Is Not Affected No functional impact on the originating component — the underlying operation continues to run normally No data loss — the suppressed entries are not persisted ; nothing else changes about the system's behaviour Error-level logs and non-matching warnings continue to be written as usual Key Diagnostic Signal Observation Significance A single message pattern accounts for > 50% of new syslog rows over a 24-hour window Strong candidate for a log-filter suppression rule The noisy line has a stable, identifiable shape (same source, same level, same template text) A regex can be written that matches the line precisely without collateral suppression The same line appears across multiple nodes / sessions / users Confirms it is a platform-wide pattern rather than a localised issue, and that property-based filtering is the right scope Facts .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The glide.log_filter.*.suppress Property Family ServiceNow exposes a generic system-property mechanism for suppressing log lines that match an administrator-supplied regular expression. Each property defines one suppression rule. The middle segment of the property name is a free-form descriptor — it has no semantic effect, and you can create as many independent rules as you need by varying it.

Field Value Property Name glide.log_filter. .suppress Type String Value A regular expression that matches the log line(s) to suppress Scope Instance-wide — applies to every node, every session Evaluation Each candidate log line is tested against all glide.log_filter.*.suppress regexes; a match causes the line to be dropped before persistence Multiple Rules Supported — create one property per pattern, using a different each time (e.g. .graphql_cancel. , .scheduler_idle. , .integration_ping. ) Property-Name Shape The portion of the property name is arbitrary but should be short, lowercase, and self-describing. It exists for human grouping and audit only; the platform does not interpret it.

glide.log_filter. .suppress Examples of well-formed property names:

glide.log_filter.graphql_cancel.suppress glide.log_filter.scheduler_heartbeat.suppress glide.log_filter.integration_poll.suppress Regex Value — Generic Shape The Value is a standard Java regular expression. Take a distinctive substring from the log line and wrap it in .* on each side:

.* .* Useful building blocks:

Fragment Purpose Example Regex Matches Raw Log Fragment .* Match any sequence of characters (use sparingly — broader regex means higher collateral-suppression risk) .*cache flush.* Record with sysID does not exist when processing cache flush \s+ Match one-or-more whitespace characters (more reliable than a literal space) .*graphql\s+$cancelled.* /api/now/graphql (cancelled by other transaction) \/ Escaped forward slash — required when the line contains URI paths .*\/api\/now\/graphql.* POST /api/now/graphql HTTP/1.1 \( $ Escaped parentheses — required when the line contains literal parentheses .*$cancelled by other transaction$.* Transaction cancelled (cancelled by other transaction) $ End-of-line anchor — useful to bound the match and avoid over-matching .*cancelled by other transaction\):.*$ ... (cancelled by other transaction): nowId=abc123 Platform-Level Behaviour: This mechanism is platform-supplied, available on every supported release, and not specific to any one component or message. Any log line that matches the regex is suppressed, regardless of which subsystem emitted it. Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } N/A

Cause .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Repetitive log entries are generated when a platform component, integration, scheduled job, or UI behaviour emits the same log line at high frequency. The emission itself is typically not a defect — the component is logging at the level it was designed to log at. The issue is one of volume and signal-to-noise , not correctness.

Typical Contributing Patterns Pattern Why It Generates Noise Rapid client-side interactions (e.g. repeated filter changes) issuing concurrent API requests Each request emits a routine warning or info entry; high concurrency multiplies the volume Multiple UI components or widgets making overlapping API calls during the same render cycle The same operation is logged once per call, generating many near-identical entries within milliseconds Scheduled jobs or heartbeats firing on a short interval Each tick writes a routine "started / completed / idle" entry, accumulating across all nodes Integration polls against external systems Each poll writes a routine status entry, especially when polling cadence is sub-minute A platform enhancement that intentionally logs a new informational signal at a high-traffic surface Volume is the consequence of the signal being attached to a hot code path; per-event behaviour is correct Why a Property-Based Filter Is the Right Lever For high-volume informational or warning lines, the cheapest correct action is to suppress at the log layer rather than modify the emitting code. The glide.log_filter.*.suppress mechanism:

Is non-invasive — no code change, no platform upgrade required Is scoped — only lines matching the regex are dropped; everything else continues to log normally Is reversible — deleting the property restores full logging immediately Is auditable — the property itself is visible in sys_properties and can be reviewed at any time Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Step 1 — Capture a Representative Log Line Open System Logs → All (or the relevant module) and filter to a recent example of the noisy entry Copy the Message field exactly as it appears — including punctuation, parentheses, slashes, and any path segments Note any portions that are variable (timestamps, session IDs, user names) — these must be replaced with regex wildcards ( .* ) in the pattern Note any portions that are stable (component name, URI path fragment, fixed message text) — these become the anchors that make the regex specific Step 2 — Construct the Regex Pattern Take a distinctive substring from the log line and wrap it in .* on each side:

.* .* Validate the pattern in a regex tester against:

Several real samples of the line you want to suppress (must all match) Several unrelated log lines from the same module (must none match) Step 3 — Create the System Property Navigate to System Properties → All Properties Create a new record with the fields below Uncheck "Ignore cache" so the property takes effect immediately — since it is being created, there is no cached value to wait for Save the record Confirm in System Logs that the matching lines no longer appear; confirm other lines are unaffected Field Value Name glide.log_filter. .suppress Type String Value The regex pattern constructed in Step 2 Ignore cache Unchecked (so the change is applied without a cache flush wait) Application Global (unless your environment standards require otherwise) Worked Examples The same property shape applies to any recurring log line — only the and the regex change. Both examples below have been validated in production: after the property was saved (with Ignore cache unchecked), the matching log entries stopped appearing in the System Logs immediately, with no impact on unrelated logging.

Example 1 — Suppress GraphQL "cancelled by other transaction" warnings A high-volume warning emitted on the /api/now/graphql endpoint when concurrent requests share the same x-request-cancelable header value:

Field Value Name glide.log_filter.cancel_warning.suppress Type String Value .*\/api\/now\/graphql\s+$cancelled by other transaction$:.*$ Status Validated in production — matching entries successfully suppressed after property update Example 2 — Suppress "Record with sysID does not exist" cache-flush warnings A repetitive entry emitted during cache-flush processing when the platform attempts to flush a record that no longer exists:

Field Value Name glide.log_filter.cache_flush_log.suppress Type String Value .*Record with sysID does not exist when processing cache flush.* Status Validated in production — matching entries successfully suppressed after property update General Template — Adapting to Any Other String To suppress any other recurring log line, follow the same shape. Replace with a short identifier for the rule, and with the distinctive substring(s) from the log line:

Name: glide.log_filter. .suppress Type: String Value: .* .* Anchor on the most stable, distinctive portion of the log line — typically the fixed message text or a unique URI fragment — and avoid bare .* patterns that could match unrelated entries.

Important Considerations No extra whitespace in the property name or value — trailing or leading spaces will silently prevent the rule from matching Uncheck "Ignore cache" when creating the property so it takes effect immediately; the property has no cached value yet Test in a Non-Production instance first, then promote to Production — the regex must be validated against real production-shape log lines, not just synthetic samples Schedule Production rollout during non-peak hours if the change will trigger a cache flush (unchecking "Ignore cache" on an existing cached property) Keep the regex specific — anchor on stable, distinguishing substrings. Avoid bare .* patterns that risk suppressing unrelated entries Document the rule — log the descriptor, the regex, the originating ticket, and the date in your change-management system so future admins understand why the rule exists Expected Outcome (Production-Validated): Matching log lines stop being persisted immediately after the property is saved with Ignore cache unchecked. The syslog table growth rate returns to baseline, and the genuine errors / warnings become visible again in the System Logs view. Both worked examples above have been confirmed effective in production environments. Watch Out — Over-Suppression: A regex that is too broad will silently hide genuine issues. After applying the rule, monitor for at least one full business cycle to confirm that error-level entries from the same component are still being captured. If anything important goes missing, tighten the regex or remove the property. Treat Suppression as a Workaround: The property hides the symptom; it does not address the underlying emission. Where the noisy line points to a behaviour that should be fixed at source (a misbehaving integration, a UI re-render loop, a scheduler configured with a short interval), log a support case to remediate the cause.