ServiceNow Platform Performance Automation Opportunities

Automation Purpose: Sustain Performance Under Growth

As data grows and usage increases, performance naturally degrades without attention. Automations can sustain performance by continuously: analyzing slow queries and recommending indexes, archiving old data, monitoring performance metrics and alerting to anomalies, optimizing database statistics.

Automated Slow Query Analysis

ServiceNow logs slow queries (queries taking over 500ms). Automation runs nightly: fetch slow query logs, aggregate by query type, calculate statistics (how many times did each query run, total time spent, average duration). Results surface top-10 slowest queries. Alert query owner (the team that created the query) recommending optimization or indexing.

Implementation: a nightly flow or scheduled script reads the slow query patterns the instance already records, aggregates them and creates a task for the platform team. Task includes query text, number of executions, average duration, recommendation (add index on field X). Database team reviews, verifies recommendation is correct, applies index or optimizes query.

Value: catches performance issues early, gives actionable recommendations, reduces reactive troubleshooting. Teams spend time on optimization rather than debugging failures.

Automated Data Archiving

Tables grow over time; old data that is no longer needed slows queries. Automation periodically archives old data: closed incidents older than 2 years, completed change orders older than 5 years. Archived data is moved to archive table, then can be deleted or retained in separate storage.

Implementation: regularly flow runs, identifies records older than archive threshold (per table), moves to archive table, validates move was successful, deletes from main table if no errors. Alert operations team after completion.

Guardrails: ensure archival complies with retention policy (do not delete data that must be kept for compliance). Test archival process in sandbox first; data loss during archival is catastrophic.

Automated Index Maintenance

Database indexes improve query performance but accumulate overhead: unused indexes slow inserts and updates. Automation: periodically review indexes, identify unused ones (not used within a period your policy sets), recommend removal. Automation can also analyze statistics (table row counts, field cardinality) and recommend new indexes for frequently filtered fields.

Implementation: periodically flow runs database analysis, compares actual slow queries to existing indexes, identifies index gaps (slow queries on non-indexed fields), recommends index creation. Index recommendations go to database team for review and implementation.

Automated Performance Alerting

Monitor performance metrics (page load time, API response time, error rate) continuously. Automation detects anomalies: if page load time jumps from 2 seconds to 10 seconds, alert immediately. If error rate exceeds a tiny share, alert. If concurrent users exceed expected capacity, alert.

Implementation: metric collection runs continuously or at regular intervals (an interval set for each metric, for example page load and table size). Thresholds trigger alerts. Alerts include context (metric value, historical baseline, recommended action). Alert routing: critical alerts to ops on-call, medium alerts to ops team Slack channel, low alerts to dashboard for review.

Value: detects issues in near-real-time, enables rapid response. Without automation, issue may go unnoticed until user complains (hours later).

Automated Query Plan Analysis

For critical queries (incident list, change request search), automation analyzes query plan: is the query using indexes or doing full table scans? Are joins efficient or should they be reordered? Automation can recommend query rewrites or indexes.

Implementation: periodically (or after major schema changes), automation analyzes query plans for top-50 queries, generates report with findings and recommendations. Query owner reviews and implements recommendations.

Guardrails and Manual Review

Automations should recommend, not execute automatically (except for safe operations like alerting or reporting). A recommended index could be wrong if recommendation engine misunderstands the query. A data archive could delete data needed for compliance if thresholds are wrong. Always require manual review of high-impact automation actions.

Automate safe actions: alerting, performance monitoring and read-only reports. Require approval for risky actions: index creation (test first), data deletion (validate retention policy), query plan changes (complex reasoning required).

Track automation success rate: did recommendations improve performance? Are index recommendations usually correct? If success rate is low, refine automation logic or disable until understood.

Choosing which automations earn a place

Automation in performance work tends to grow by accident. Someone writes a scheduled job to clear old drafts, another adds an alert for a slow integration, and a third builds a weekly report that quietly triggers the same queries the dashboards already run. A year later nobody knows which jobs are still useful. The discipline that prevents this is to judge each proposed automation by the decision it supports, the action it is allowed to take and the way it is undone. The table below is a way to make that judgment explicit before anything is scheduled. Each row should point at a measure the team has already defined, such as the ones in the KPI guide, so that the automation and the review agree on what counts as slow.

The rule that separates the safe rows from the risky ones is simple. An automation may create information freely. It may change data only where the change can be reversed from a known source, and it should never change structure, such as indexes or schema, without a person approving it.

Piloting one automation without creating a new problem

A pilot should be small enough to stop quickly and large enough to tell you whether the decision it supports is worth making. The steps below keep the pilot honest.

1. Write down the decision the automation informs and the person who will make it.
2. Run the automation in a read-only mode against production data for a full cycle, and save its output without acting on it.
3. Have the decision owner review the saved output and mark each item as useful, noise or wrong.
4. Count the noise and the wrong items. If the noise is higher than the useful items, change the rule before you enable any action.
5. Enable the action for one table or one team, with the reversal step written down and tested once.
6. At the end of the pilot, the owner decides whether it grows, changes or stops.

What tends to break once an automation is live

The first failure is alert volume. An automation that is correct but noisy trains people to ignore it, and the first real problem then sits unread in a queue. The second is a feedback loop, where an automation’s own writes trigger the rule that runs it again, and the job grows its workload every cycle. The third is a silent dependency: a clean-up job assumes a table is never read by a report, and a quarter later a report fails. Check for each of these when you review a pilot, not after an incident. Where a pilot’s output needs an owner who can approve changes, the governance model sets out who that is and what they are allowed to decide.

When to leave the work manual

Keep a task manual when it happens rarely and the judgment is the valuable part. A decision to retire a report, a choice between two index designs or a conversation about how long to keep closed records is not one an automation should make. Automating a rare decision mostly hides the reasoning from the next person who has to make it. Where the rare decision is a fix to a slow screen, the common mistakes guide lists the patterns to check first.

How do we know an automation is still doing its job?

Keep a short log of what it proposed, what the owner did with each proposal and what happened afterward. If the owner rejects most proposals, the rule is wrong, and the log shows which rule to change.

Who should be allowed to schedule a new automation?

Someone who can also explain how it is reversed. Scheduling rights for jobs that delete or move data should be narrower than rights for jobs that only report.

Is a scheduled job the same as an automation?

In practice, yes, and it should be reviewed the same way. Some performance problems come from jobs that were scheduled for a one-time purpose and never removed.

What is the first automation a small team should try?

A read-only report that flags repeated slowdowns for named views. It costs little, changes nothing and tests whether the team reads what it is sent.

The article on automation exception handling covers the failure side of the same decisions in more detail.