Refresh intervals and live data feeds for real-time monitoring

The wall screen that lied. Picture a storm night in a county emergency operations center. The utility outage dashboard is on the big wall screen, and it looks calm. Twelve outages, all assigned, crews on the way. The duty manager holds back the extra crews. Then a supervisor walks in with a phone showing ninety outages. The wall screen had loaded once at the start of the shift and never updated. Nobody noticed, because a stale dashboard looks exactly like a quiet one. In this lesson you'll make sure your dashboards keep up with the data, and that everyone in the room can see how fresh the numbers are.

What you will learn. Here's the plan. First, you'll set refresh intervals, so the maps, indicators, charts and lists on a dashboard update without anyone pressing reload. Second, you'll learn to pick the right interval. Faster isn't always better, and we'll put numbers on why. Third, you'll look at where live data actually comes from, including Living Atlas feeds and your own update scripts, and you'll add a small freshness signal so viewers can trust what they see. By the end, your storm night wall screen will tell the truth.

Where refresh actually happens. Let's follow the data from start to finish. A crew edits a record in a field app, or a sensor posts a reading, and that lands in a hosted feature layer. The dashboard doesn't watch that layer by itself. Instead, the layer carries a refresh interval, and every dashboard element built on that layer re-queries it on that schedule. So the setting lives on the layer, either in the web map or on the layer item. Keep one idea in mind: refresh only fetches what's already there. If nothing upstream is writing new records, a fast refresh just shows the same old data more often.

Setting the refresh interval. Here's how to set it. Open the web map your dashboard uses in Map Viewer. Select the outage layer, open its Properties panel, and find the Refresh interval setting. Switch it on and type a value in minutes. The smallest you can enter is zero point one minutes, which works out to six seconds. Save the web map. For a layer you added to the dashboard directly, rather than through a map, set the same option in the layer item's settings. Reopen the dashboard, and the map, the outage count and the list of open tickets all start updating together, with no page reload.

Match the interval to the data. So how fast should you refresh? Ask one question: how often does this data really change, and how quickly does someone need to act? Traffic incidents change minute by minute, and dispatchers react fast, so one minute fits. Storm outages move quickly too, so try one to two minutes. Water main breaks are reported, then worked for hours, so about five minutes is plenty. Three-one-one service requests, from the non-emergency city hotline for things like potholes and missed trash pickups, come in all day but rarely need action within seconds, so ten or fifteen minutes is fine. A five minute interval means twelve refreshes an hour, which is plenty for most operations.

Where live data comes from. Refresh needs a source that actually changes. The quickest win is Living Atlas, Esri's curated library of ready-to-use layers. Its live feeds, such as weather alerts, stream gauges and wildfires, are kept up to date by Esri, so you can add them to a storm response map and set a refresh interval straight away. Your own data usually arrives through field apps writing to hosted feature layers, or through a scheduled Python script that copies records from a work order system every few minutes. For high-frequency sensors, a streaming service, such as a stream layer, pushes each new reading to the map as it arrives.

Worked example: the cost of fast refresh. Every refresh can send up to one query from every element on every open screen. Let's count. Say forty people have the storm dashboard open, and six elements read the outage layer. The script works out refreshes per hour as sixty divided by the interval, then multiplies by viewers and elements. At zero point one minutes that's up to one hundred forty-four thousand queries an hour against one layer. At five minutes it drops to two thousand eight hundred and eighty. Elements that share a layer and cached responses can bring the real number down, so treat these figures as a rough worst case. On a public-facing dashboard, anonymous viewers count toward this load too. A busy service slows down for everyone, including the field crews editing it. So choose the slowest interval your operations can live with.

Show viewers how fresh the data is. A refresh interval keeps the screen updating, but viewers still need proof. Add a small indicator element that shows the most recent edit date in the layer, using the maximum of the last edited date field as its statistic. This field needs editor tracking turned on; for a feed or script layer, use the feed's own update time. Label it "Last update" and place it near the title. If the outage count hasn't moved but the last update says two minutes ago, it really is quiet. If it says forty minutes ago, investigate. First reload the screen or open the dashboard on another device, because a frozen screen freezes this indicator too. If the time is still old, check the feed or the update script. On a quiet night it will also look old, so compare it with a feed heartbeat.

Keeping wall screens alive. Wall screens fail in boring ways. A laptop goes to sleep, a browser tab gets throttled in the background, or a sign-in session expires overnight and the screen shows a login page nobody sees. Give each wall screen its own browser profile in full screen with the dashboard tab kept in front, turn off sleep and screen savers, and use an account whose session suits the length of a shift. Then add one line to your shift change checklist: confirm the last update time is current. It takes ten seconds.

Common mistake: fastest refresh everywhere. The most common mistake is setting every layer to the fastest refresh, just to be safe. Teams do this with the county boundary, the substation locations and the outage points all set to six seconds. Boundaries and substations never change during a storm, so those queries are pure waste. Meanwhile the outage service gets hammered, field edits start to lag, and the dashboard ends up less current than it would be at a calmer pace. The fix is simple. Refresh only the layers that actually change, give each one the slowest interval that still supports the decisions, and leave static reference layers alone.

Recap. Let's recap. Refresh intervals are set on layers, in Map Viewer or on the layer item, and every dashboard element built on that layer follows along. Choose the interval from the data and the decision: one minute for traffic incidents, several minutes for water main breaks, longer for service requests, and remember that each refresh multiplies by every viewer and every element. Finally, a simple last update indicator turns a silent failure into something anyone in the room can spot at a glance.

Your exercise. Now it's your turn. Open a dashboard you've built, ideally the outage or traffic incident one from earlier lessons. Pick the one layer that changes most often and set a refresh interval that fits it, using this lesson's guide. Add a last update indicator near the title. If the layer has no last edited date field, turn on editor tracking first. Then edit a feature in that layer, in Map Viewer or a field app, and time how long it takes to appear on the dashboard. Write down the interval, the delay you measured, and one sentence explaining your choice. Bring those notes to the next lesson, where you'll build the full traffic incident project.