What "real-time" website monitoring actually means

"Real-time" is doing a lot of work in monitoring-tool marketing. It's used for services that check a page once an hour and services that check it every couple of seconds — and, confusingly, for one path (X/Twitter) where "checking" isn't even the right verb. If a claim like this matters to your buying decision, it's worth taking apart into the pieces that actually determine how fast you find out something changed.

Three delays, not one

"How fast will I know?" is really three separate numbers stacked on top of each other:

• Polling interval. How often the monitor's server fetches the page (or, for a push source, how often it isn't polling at all — more on that below). If a tool checks every 15 minutes, a change that lands right after a check waits up to 15 minutes before anyone even looks again.
• Detection latency. The time between the fetch happening and the tool deciding "this is different." Usually this is milliseconds — hashing or diffing a page is cheap — but it's a distinct step, and it's where false positives get filtered (or don't).
• Delivery latency. The time between "we detected a change" and the alert actually reaching you — email queued and sent, a push payload delivered to your phone, a webhook POST landing on your server. This is the delay most monitoring marketing quietly skips, and it's often the biggest of the three when something goes wrong upstream (a provider's queue backs up, a network path degrades, your phone is asleep and the OS defers the push).

A tool can genuinely check every second and still deliver a "real-time" alert five minutes late if its email provider is having a bad hour. Polling interval is the number everyone quotes because it's the flattering one; delivery latency is the one that actually determines whether you found out in time to act.

Why most monitors check every 5, 15, or 60 minutes

This isn't laziness — it's two real constraints that scale badly with frequency:

• Cost. Checking a page once an hour costs a monitoring service roughly 1/720th of what checking it every 5 seconds costs, in compute and bandwidth, across every tracker on every customer's account. A free or entry tier has to check infrequently or lose money on every user who doesn't upgrade.
• The target site rate-limits you. Hammering someone else's server every couple of seconds from the same IP, on hundreds of trackers, is the kind of traffic pattern that gets an IP range throttled or blocked. Any monitoring service running at high frequency has to spread load, back off on errors, and generally behave — which is engineering effort, not a switch you flip.

Put together, a slower default interval on entry-level plans is a rational business decision, not a technical ceiling — it's what lets a free tier exist at all. The general pattern across this market is that free and entry tiers check on the order of tens of minutes to an hour, and faster cadences are gated behind paid plans, because both of the constraints above scale directly with check frequency.

TrackerHub's actual number, measured

Rather than assert a check interval, here's the real one, from a tracker's own check history: 43,200 checks recorded against a single tracker over a 24-hour window. That works out to roughly one check every 2 seconds (86,400 seconds ÷ 43,200 checks = 2 seconds), sustained across the full day — not a burst average.

The method is deliberately boring: count the rows in that tracker's check history for a rolling 24-hour window, divide by 86,400. No sampling, no best-case cherry-pick. It's the same number the tracker's own history would show anyone who looked. This applies to page/price/restock/RSS-style trackers — the ones that work by fetching a URL on an interval. It does not apply to X/Twitter, which uses a fundamentally different mechanism, covered next.

The X/Twitter path is not polling at all

For X (Twitter) accounts specifically, TrackerHub doesn't poll a profile page on a timer. It holds an open connection to X's official Filtered Stream API — a push endpoint, not a request/response one. Posts matching a rule (e.g. "new posts from this account, excluding retweets and replies") arrive on that open connection as X emits them, rather than TrackerHub asking "anything new?" on a schedule.

A few implementation details worth being specific about, since this is the part most monitoring tools can't actually claim:

• The connection requests tweet.fields=created_at explicitly — the default Filtered Stream payload doesn't include a post's creation time, so without asking for it, the gap between "posted" and "alerted" would be unmeasurable rather than just unstated.
• On a matched post, the actual delivery latency is computed as now − created_at and included in the alert itself as a plain-language line (e.g. "caught 1.8s after posting"), not asserted as a fixed number.
• X allows exactly one concurrent Filtered Stream connection per app. If that connection silently dies — a TCP hang without a clean close — a watchdog checks every 30 seconds whether any data (including X's own ~20-second keep-alive heartbeat) has arrived in the last 90 seconds, and forces a reconnect if not. A reconnect after a drop happens on a 5-second backoff.

This matters because "we check X every N minutes" and "we hold a push connection to X's own stream" are genuinely different architectures with different failure modes, and it's worth knowing which one a tool is actually running before trusting a claim about tweet alert speed.

The comparison at a glance

What a fast poll interval does not promise

This is the part worth saying plainly, because it's the part every vendor has an incentive to skip: a 2-second poll interval does not guarantee a 2-second alert. It guarantees TrackerHub looked at the page 2 seconds ago. What happens after that — detection, then delivery — adds real time, and delivery is where things can actually fail rather than just be slow:

• Email, Telegram, Slack, Discord, and webhook deliveries all depend on a third-party service accepting the request. That service can be slow, rate-limited, or down.
• TrackerHub is in beta, with no uptime or delivery guarantee. Providers fail. We've had a real incident where an email provider's sending cap caused a multi-day gap in delivered alerts before it was caught — which is the exact reason a fallback chain of independent email providers now exists (if the primary rejects a send, the next provider in the chain gets tried automatically, rather than the alert silently dying). That fallback chain reduces the failure mode; it doesn't eliminate the possibility of a provider having a bad hour.
• A push notification depends on your phone or OS delivering it promptly — something no monitoring vendor controls end to end.

None of this is a reason to distrust fast-interval monitoring. It's a reason to distrust any claim that stops at the polling number and doesn't mention the rest of the pipeline. If you want the honest version of "how fast will I actually know," ask about all three delays — not just the flattering one.

How to check any vendor's real number yourself

You don't have to take a monitoring vendor's word for its check frequency, and it's worth being skeptical of any claim that can't be checked. A few concrete ways to verify:

• Ask for the check history. Any tool that actually checks frequently can show you a timestamped log of individual checks against a specific tracker. If a vendor can't produce that, the "real-time" claim is unverifiable by definition.
• Watch your own server logs. If you control the target page, its access logs show exactly how often a given monitoring service's IP is requesting it — a direct, independent measurement that doesn't depend on trusting the vendor at all.
• Time a controlled change. Change something small on a page you control, note the timestamp, and see how long the alert takes to arrive. This measures the whole pipeline — poll, detect, deliver — which is arguably the more useful number anyway, since it's the one that actually affects you.

None of these require insider access. They're the same checks worth running against any monitoring tool, including this one, before trusting a marketing page's use of "real-time."

Why this number changes by plan tier, and why that's disclosed rather than hidden

The 43,200-checks-a-day figure above is what a standard web/price/restock/RSS tracker gets on a paid plan. It's stated as a measured fact from one tracker's real check history, not as a blanket promise that every tracker on every plan behaves identically forever — infrastructure capacity, the target site's own rate-limiting, and plan tier all factor into the actual cadence a given tracker sees. The honest framing is: this is the real number from a real tracker, checked the way described above, not an average, a best-case, or a number pulled from a spec sheet nobody measured against.