Realtime monitoring
The 30-minute window, 60-second polling and caching, what each card measures, plan limits, and what happens when GA4 is unavailable.
Window and refresh mechanics#
The realtime page is /dashboard/mkit/live; /dashboard/reports/realtime is not a separate feature and redirects there. Data comes from GA4 Realtime via GET /api/v1/reports/live.
| Item | Rule |
|---|---|
| Window | The last 30 minutes. No minuteRanges or start/end time is sent, so the GA4 Realtime default window applies; product and page copy consistently describe it as "the last 30 minutes" |
| Refresh | The frontend polls every 60 seconds |
| Backgrounded tab | Polling pauses when the tab is hidden; it also auto-pauses after 10 minutes without user interaction |
| Server cache | Live results are KV-fresh for 30 seconds with a 60-second TTL; the 7-day average is cached for 1 hour |
| Manual refresh | Pro 100/day, Business unlimited; the count lives in browser localStorage, so it is a local frontend limit, not a server quota |
Note: The lightweight realtime-visitors endpoint GET /api/v1/reports/realtime returns only visitors and caches for 30 seconds; the realtime pill on /dashboard/visitors also uses it, polling every 30 seconds.
What each card measures#
The Live endpoint issues six GA4 Realtime queries: total active users, the minute series, pages, countries, devices and events.
| Card / field | Definition |
|---|---|
| Active users active_users_30m | Total activeUsers with no dimension |
| Avg per minute avg_per_min | The 30 minute-point activeUsers values summed and divided by 30 |
| vs 7-day daily avg vs_7d_pct | Current 30-minute active users compared with the average daily active users of the past 7 days, not the same time slot 7 days ago |
| Top pages top_pages | unifiedScreenName × activeUsers / screenPageViews, returning screen, path, users, views_30m |
| Top countries countries | country × activeUsers |
| Top devices devices | deviceCategory × activeUsers, with a computed pct share |
| Top events events | eventName × eventCount |
Note: The timeline uses the 30-point minutesAgo × activeUsers series; Top pages, countries, devices and events are sorted by users or event count descending.
Plans and limits#
| Plan | Visibility | Manual refresh |
|---|---|---|
| Free | locked: returns { locked: true, plan } and shows the locked card | — |
| Pro | Top 5 pages and Geo (countries) | 100/day |
| Business | Top 10 pages and Geo (countries) | Unlimited |
Note: The manual-refresh allowance is counted in frontend localStorage per day, not enforced as a server quota; clearing site data or switching browsers resets it.
When upstream fails#
When the GA4 Realtime request fails, the backend does not throw a 500. It returns ok:false, stale:true and an error message.
- A red banner at the top of the page says the data shown may be stale
- The last successful data is kept, so rendered cards and charts are not cleared
- Automatic polling continues and the banner disappears after the next successful refresh
Note: This fallback covers upstream fetch failures only; Free locking, quota and authorization issues follow their own branches.
Accuracy notes#
- GA4 Realtime data is not fully processed yet; numbers in the 30-minute window can still change and should not be reconciled one-to-one with next-day historical reports.
- The window is actually the GA4 Realtime default (no explicit minuteRanges is sent), described consistently as the last 30 minutes.
- Active users are deduplicated users; event counts accumulate occurrences, so the two cannot be added together or converted into each other.
- vs_7d_pct compares against the 7-day daily average, not the same slot, so changes in day-to-day traffic mix affect the percentage.
Tip: Use realtime monitoring for current traffic and sudden events; for trends, use historical reports from the same source and the same time window.
Related docs#
- Conversion tracking report: /conversions
- Ecommerce attribution report: /ecommerce-report
- Data latency & metric definitions: /data-latency
- Keywords report: /keywords