Two dashboards show the same Bitcoin price, to the dollar. One number is 300 milliseconds old. The other is 45 seconds old. Both are labeled "live." Neither is exactly lying, and that's the problem.
"Live" is a claim about freshness, and freshness varies by orders of magnitude across the feeds a dashboard, trading tool or AI agent pulls in. During a rally in September 2026, the free price aggregator we keep as a last-resort fallback was running roughly $550 behind the exchange streams our dashboard reads. Same asset, same moment, both technically live. Knowing where each number sits on the spectrum is the difference between a useful screen and expensive theater.
The spectrum: from milliseconds to minutes
Real-time isn't yes or no. Every feed sits somewhere on a spectrum.
At the fast end are exchange WebSocket streams. Binance documents its trade and best-bid/ask streams as "real-time," one message per event, while its 24-hour ticker stream updates once a second and its order-book depth streams every 100 or 1,000 milliseconds. Coinbase's ticker channel fires on every match, its ticker_batch channel sends at most one update every five seconds, and level2_batch bundles order-book changes every 50 milliseconds. Even streaming comes in grades, and the channel you subscribe to decides which grade you get.
In the middle is polling. You call an endpoint, wait, render, call again, and anything that happens between calls stays invisible until the next one. For a lot of data that's fine. The USGS rebuilds its earthquake summary feeds once a minute, so polling them every second buys you nothing but load.
At the slow end are cached snapshots: a response stored for five minutes, a feed that publishes once a day. Plenty of dashboards still call that live.
A good dashboard mixes all three on one screen, and that's correct. The job is matching each feed's refresh rate to how fast the underlying thing actually changes.
Sometimes the delay is the rule
Some latency isn't an engineering choice at all.
Licensing. US exchanges treat stock data shown within 15 minutes of its release as real-time data, which needs a license and usually per-user fees. Nasdaq's data policy and NYSE's both define delayed data as disseminated at least 15 minutes after the exchange releases it, and both require a visible notice along the lines of "Data Delayed 15 minutes." That's why so many free quote pages lag the market. The delay is what makes them free.
The chain's own clock. Blockchains keep a pace no dashboard can beat. Bitcoin produces a block about every 10 minutes on average, and many services wait for several confirmations before treating a payment as settled. Ethereum runs 12-second slots grouped into 32-slot epochs, and a block is finalized after about two epochs, roughly 13 minutes. Solana is far quicker: its slots ran at 400 milliseconds for years and were cut to 300 in two steps in August 2026. Under its current TowerBFT consensus, though, a block is only finalized after about 32 slots, which the Solana Foundation puts at 12.8 seconds at the old slot time. Its Alpenglow upgrade targets finality in roughly 150 milliseconds. Feature activation on mainnet is scheduled to begin September 28, 2026, on a release schedule Anza labels tentative, so as of this writing Alpenglow isn't live.
For anyone building on chain data, the takeaway is simple: a price can stream in milliseconds while the transaction behind it takes seconds or minutes to become irreversible. "Live" and "final" are different questions.
Why latency matters: the cost of being behind
Picture a trading bot or an AI agent acting on market data. It sees a price and sends a limit order at it. By the time the order lands, the market has moved, and the order misses or fills worse than planned. The staler the input, the wider that window.
How much that matters depends on what happens next. For a market maker, milliseconds are money. For someone glancing at a second monitor, one second is plenty. For trend analysis, fifteen minutes is fine.
Perception matters too. Jakob Nielsen's response-time limits still hold: about 0.1 second feels instantaneous, about 1 second keeps a user's train of thought intact, and past 10 seconds attention drifts. A ticker that moves every second feels alive. One that moves once a minute feels broken, even when minute-level data is all the source offers.
Pushing lower has a price. Redrawing every 100 milliseconds instead of every 300 roughly triples the work, and the battery drain with it. The question is whether anyone can tell.
How TerminalFeed chooses latency per source
The TerminalFeed dashboard runs more than a hundred panels on dozens of upstream sources, and each gets its own freshness budget. Here's what a handful of them actually do:
| Feed | How often the source changes | What the dashboard does |
|---|---|---|
| Bitcoin price | Every trade, many per second | Binance and Coinbase WebSockets side by side; the screen updates at most once a second on desktop, every three seconds on mobile |
| New Bitcoin blocks | About every 10 minutes on average | Pushed over mempool.space's WebSocket as soon as a block is found |
| Wikipedia edits | Continuously | Wikimedia's Server-Sent Events stream, throttled to one entry a second (one every three seconds on mobile) |
| Earthquakes | USGS feeds rebuild every minute | Checked every two minutes through a two-minute backend cache |
| Hacker News front page | Every few minutes | Polled every 90 seconds, cached for two minutes |
| US stock quotes | Continuously in market hours | A background sweep every five minutes; every quote carries its age |
| Crypto Fear & Greed Index | Once a day | Cached for five minutes, which is already generous |
A few rules sit behind that table.
Stream the number people stare at. The Bitcoin price is the figure people watch most, so it streams from two exchanges at once. Visitors in the US can't reach Binance's global stream, so Coinbase carries them. Only when neither socket is alive does the dashboard fall back to asking its own backend, because a slow price beats a frozen one. (More on that choice.)
One upstream call serves everyone. Polled feeds go through the dashboard's own backend, a Cloudflare Worker with a per-feed cache plus a shared edge cache in each data center, capped at ten minutes. A thousand visitors asking for earthquakes in the same two minutes cost USGS a handful of requests, not a thousand. When an upstream source fails, the backend serves the last good copy instead of an error.
Show the age, not just the value. The stock panel is honest near-real-time. Our quote provider's free tier allows 60 calls a minute and the dashboard tracks about 130 symbols, so a background job refreshes them one call at a time every five minutes. Each quote carries its timestamp, and anything older than 12 minutes is dimmed and marked stale. A number that admits its age is more useful than one that looks fresh and isn't. Where a feed has no reading at all, the dashboard leaves a gap rather than inventing a number.
Watch for feeds that stop moving. The quietest failure is a source that keeps answering with the same data. A Feed Health panel fingerprints each feed's payload and flags any that hasn't changed in 48 hours or has broken its own usual rhythm. A cache can make a dead source look alive indefinitely, so something has to check.
The hidden cost: bandwidth and battery
A raw trade stream in a busy market delivers many messages a second, and each one gets parsed even if it's never drawn. On a desktop that's noise. On a phone it's battery.
So the dashboard cuts its appetite on mobile: WebSocket redraws drop to one every three seconds, polling intervals double, and ambient animations switch off. It also stops polling when nobody is looking. Once a tab has been hidden for 15 seconds, requests to the backend are parked, then released on a stagger when you come back. A visitor on cellular data shouldn't pay for updates they can't see.
True real-time is rare and expensive
Serious low-latency trading is a different sport. Firms rent rack space inside the exchange's own data center, buy direct feeds and measure in microseconds. A browser can't play that game. Physics sets the first floor: light in optical fiber covers roughly 200 kilometers per millisecond, so an ocean round trip costs tens of milliseconds before any server does any work. Add the upstream API, your backend, the browser's event loop and the odd garbage-collection pause, and a web dashboard is doing well to stay within about 100 milliseconds of the source.
Below that, people can't tell the difference anyway; it's Nielsen's threshold for "instantaneous." What they do notice is jitter. A feed that's steadily 500 milliseconds behind feels better than one that swings between 100 milliseconds and two seconds. Consistency beats raw speed.
Making the tradeoff decision
Before picking a refresh rate, ask:
- What does the user do with this number? If they trade on it, milliseconds matter. If they read it, seconds don't.
- How often does the source actually change? Polling a daily index every second is waste. So is polling USGS faster than once a minute.
- Is the delay legal or physical? Free stock quotes run 15 minutes behind by design, and Ethereum finality takes about 13 minutes however fast your socket is.
- What does being behind cost? A missed fill costs money. A stale headline ages gently. An earthquake alert should be fast.
- Will this run on a phone? Then throttle, cache, and pause when the tab is hidden.
- Can the user see how old it is? If not, add a timestamp before you add speed.
The best dashboards don't chase sub-second latency everywhere. Bitcoin price earns a stream. Wikipedia edits earn SSE (the tradeoffs are in WebSocket vs Server-Sent Events). Hacker News earns a 90-second poll. The Fear & Greed Index earns a lazy cache. Each choice is right for its data.
See the mix in action: streamed prices, pushed blocks and polled feeds side by side, each on its own clock.
Explore TerminalFeed Dashboard"Real-time" now gets stretched to cover everything from a Binance trade tick to last month's CPI print, so the label alone tells you almost nothing. Ask two questions instead: how old is this number right now, and is that old enough for what I'm about to do with it? Answer honestly, put the answer on screen, and the dashboard earns trust instead of just looking busy.