How to Auto Refresh Dashboards in ServiceNow Without Hurting Performance

BillMartin · Monday

You can flip on auto refresh in a ServiceNow dashboard in seconds. The problem is what happens after that. Dashboards can look more “live,” but the platform may start slowing down, reports begin to drag, and the instance can act unstable. That isn’t a reporting bug. It’s capacity pressure caused by how dashboards run.

This walkthrough is for ServiceNow administrators, platform owners, developers, and architects who build dashboards that leaders actually use. You’ll leave with three clear outcomes:

Understand how dashboard auto refresh works in ServiceNow
See how refresh ties straight to platform capacity
Start designing dashboards that stay accurate without quietly eating your instance

Why ServiceNow dashboards don’t auto refresh by default

ServiceNow dashboards do not auto refresh by default. That’s not an accident. The platform is built like a canvas, you build and configure what sits on top. Refresh behavior is part of that shared responsibility.

When you turn on auto refresh, you’re not changing how the page looks. You’re changing how often the system has to run the work behind every widget. That means CPU, memory, and network traffic.

Dashboard settings walkthrough (where auto refresh lives)

A simple way to see it is to open a dashboard (for example, an Asset dashboard), then:

Go into edit mode (top right).
Open dashboard settings.
Find the auto refresh option and enable scheduled repetition.
Choose the interval.

The UI makes this feel harmless. The interval question is the real one: how real-time does it need to be, and why?

Before you set any refresh schedule, you need answers to a few basics:

How often does the data actually change?
Who is the audience?
Is this for operational awareness or executive insight?
Where does this dashboard sit in daily workflows?

What a dashboard really is (and why it matters)

A dashboard looks like one thing, a single page with tiles and charts. Under the hood, it’s a bundle of smaller pieces that each do their own work.

How widgets work across layers

Think of a dashboard as a collection of widgets. Most widgets are report-based. Each widget runs its own call to the backend.

A simple way to picture the flow is three layers:

Web front end: what you see in the browser
Application layer: where your scripts run, including Glide APIs like GlideRecord
Database layer: where the data sits (you don’t access it directly)

ServiceNow is cloud-based, so you work in the application layer. When a widget needs data, it typically uses GlideRecord logic in the application layer, that gets translated into a database query, then results come back up the stack.

That “up and down” movement is real work. Each refresh creates network calls, application processing, and database load.

Widget independence (each one is its own workload)

Each widget is independent. A dashboard with 10 widgets is not one query. It’s many separate queries, each with its own execution path.

That independence matters because dashboards scale load in a way people don’t always notice:

More widgets means more backend calls.
More users means the same widgets run repeatedly.
Shorter refresh intervals multiply everything.

In practice, every widget behaves like a small app making synchronous requests for data.

Auto refresh is not a UI setting, it’s capacity planning

This is the pitfall: teams turn on auto refresh so dashboards look current, then performance starts to drop. The platform slows, users complain, and the cause can be hard to spot if you treat refresh as a harmless display feature.

Auto refresh is a capacity planning decision, not a convenience toggle.

Calculate your load (simple math, real impact)

Use a basic example from the video:

If you have:

10 report widgets
20 users viewing the dashboard
a 1-minute refresh interval

You’re effectively running 200 report queries per minute.

That number surprises people because it doesn’t feel like 200 queries. It feels like a page updating.

If you stretch the time window, you get a clearer picture:

What you have	What you set	What the platform runs
10 widgets	20 users	200 queries per refresh cycle
1-minute interval	60 minutes per hour	12,000 queries per hour

The exact number can vary based on widget behavior and caching, but the core point holds. A “small” refresh interval can become a steady stream of database work.

Why dashboards can slow down as load climbs

Many report-based widget calls are synchronous in nature. That means requests line up in a queue.

When you have too many requests at once, you get bottlenecks:

Widget load times climb.
Dashboard render time gets worse.
Users start refreshing manually because it feels slow.
The instance can feel unstable under peak usage.

When people call this a “reporting problem,” they miss the real cause. The report is just where you see the symptoms. The root issue is capacity, workload, and design choices.

Questions you should answer before enabling auto refresh

If you’re responsible for dashboards, ask these questions early, not after performance tanks:

How many users will access this dashboard?
What tables are the widgets querying?
How complex are those queries?
How often does the data change?
What happens if 50 users open it at once?

You also want to be clear on intent:

Operational dashboards often need fresher data.
Executive dashboards often don’t need minute-by-minute updates.

If the data changes once a day, a 1-minute refresh interval is waste. It creates load without adding insight.

Performance Analytics widgets vs report-based widgets

Not all widgets behave the same way. The difference between report-based widgets and Performance Analytics (PA) widgets changes how load hits your instance.

Report-based widgets (consume capacity at view time)

A standard report widget runs queries when someone loads the dashboard (and again each time it refreshes). That means the cost shows up at view time, right when users are active.

If you have many users and many widgets, that cost stacks quickly.

Performance Analytics widgets (shift work to scheduled jobs)

PA widgets rely on precomputed indicators. That means the heavy work happens on a schedule, often off-peak. You’re shifting load away from “every time someone opens the dashboard” toward controlled collection times.

This circles back to the key requirement question: how real-time does this need to be?

If your leaders want trend and progress views, PA can be a better fit because it avoids constant live querying.

A simple rule that came through clearly:

Default executive dashboards to Performance Analytics when possible.
Use report widgets when you truly need live reads, and only after you understand the cost.

Techniques to keep dashboards fast without “silent” load

You don’t have to choose between stale dashboards and a struggling instance. You can design dashboards so they stay useful while keeping load predictable.

Use data caching (reduce repeated database hits)

One approach highlighted is data caching.

The basic idea:

Run a bigger query once.
Store the results in memory on the server side (in the application layer).
Refresh that cached data on your schedule.

Instead of every widget and every user running the same expensive query repeatedly, your widgets can reuse the cached dataset until you refresh it.

Why this helps:

You cut down direct database hits.
Widgets can render faster because data is closer.
Refresh timing becomes a planned decision, not a constant drain.

If you’ve been relying on auto refresh to keep dashboards “current,” caching gives you a cleaner way to control how often the heavy work happens.

Implement lazy loading (so widgets don’t all hit at once)

Another technique mentioned is lazy loading. Since widgets are independent, you can design or configure them so they load separately, rather than forcing the entire dashboard to complete every query before the page becomes useful.

In the video’s flow, you handle this at the report level by opening the report and adjusting its data update behavior (shown in the lower right of the report configuration area).

The outcome is practical:

Each widget loads based on its own needs.
You can reduce “all at once” spikes.
You can manage heavy widgets differently than light ones.

This is a better mental model: treat each widget like its own mini workload, because that’s how the platform treats it.

A short design checklist you can use in reviews

If dashboards are important in your org, include refresh behavior in design reviews. Keep it simple:

Define the audience.
Justify the interval.
Understand the capacity cost.
Review widget count and query complexity before rollout.

This turns dashboards from a UI task into an architecture task, which is where it belongs.

Best practices you can apply right away

A few points stand out as rules you can actually follow, even if you’re inheriting messy dashboards.

When to avoid auto refresh

Avoid auto refresh when:

You can’t explain the query cost of each widget.
The dashboard is used by many people at once.
The data changes slowly (daily or weekly), but refresh is set to minutes.
You’re building executive dashboards that can be served by PA indicators.

Most of the time, the safest default is: don’t enable auto refresh until you’ve sized the load.

Treat dashboards as platform workloads

If you want stable reporting, treat dashboards like any other workload you’d plan:

Count widgets.
Understand query patterns.
Consider concurrency (how many users at once).
Decide when work runs (view time vs scheduled jobs).

That’s how you avoid the slow creep where dashboards “worked fine,” then the instance grew, usage increased, and suddenly everything feels unstable.

Prompts worth answering in your own instance

These questions from the video are worth writing down and answering with your team:

Do you know how many queries your dashboards generate per hour or per day?
Who is the audience, and how often does the data change?
Is this dashboard for operational awareness or executive insight?
What happens if 50 users open it at the same time?
Have you traced performance issues back to dashboards before?

If you can’t answer these, auto refresh is a risk.

Conclusion: keep dashboards accurate without draining the instance

Auto refresh in ServiceNow isn’t a harmless convenience. It’s a capacity decision that can quietly turn dashboards into a steady load generator. When you plan refresh behavior, understand widget independence, and pick the right approach (PA indicators, caching, lazy loading), you protect instance stability and keep reports trusted.

Now look at your most-used dashboard and answer one question honestly:

do you know what it costs to keep it “live?”

If you can measure that and justify it, your dashboards stop being decoration and start acting like real architecture.