Real-time updates & data freshness
"How fresh is this number?" has a different answer per platform. Some of the 83 integrations push events to Ploxir the moment something happens; the rest are polled on a background schedule. This page tells you honestly which is which, how the manual Refresh button fits in, and how updates reach your open browser tab without a reload.
The three freshness tiers
1. Push — set up automatically
For these ten platforms, Ploxir registers a webhook with the provider the moment you connect. No setup on your side — a new charge, order, or ticket appears on your dashboard within seconds of the provider sending it:
Stripe, Shopify, Patreon, Twitch, Paddle, Lemon Squeezy, PayPal, Beehiiv, Zendesk, Datadog.
If auto-registration fails (for example, the API key you pasted lacks webhook permissions), the source still works via polling — the source row shows webhook setup failedwith the provider's error, and Ploxir retries the registration on the next sync.
2. Push — paste a receiver URL once
Some platforms deliver events but don't let Ploxir register the webhook via API. For those, Ploxir gives you a dedicated receiver URL to paste into the provider's settings once — after that, they update live too. This group includes RevenueCat, Gumroad, App Store (Server Notifications Version 2) and Play Console (Real-time developer notifications via Pub/Sub). Step-by-step instructions for each are in Connecting sources.
Until you paste the URL, these sources behave like tier 3: polled on the background cadence, and always refreshable on demand.
3. Poll — background reconciliation
Everything else — GA4, Plausible, Google Ads, LinkedIn Ads, Mixpanel, Amplitude, PostHog, YouTube, AdSense, eBay, Square, crypto wallets, and most of the remaining catalog — has no push surface. Ploxir re-fetches these on a per-platform schedule (table below), and the Refresh button forces a fetch right now.
Poll cadences
A background reconciliation loop scans every 30 minutes and re-syncs each source whose last sync is older than its platform's cadence:
| Cadence | Platforms | Why |
|---|---|---|
| 2 hours | Datadog, Sentry, crypto wallets | Datadog pushes alerts, but the metric bodies both platforms chart (APM, sessions, error counts) must be polled — a tighter cadence keeps those closer to live. Wallet balances have no webhook at all. |
| 6 hours | The default — every other platform | Also runs as a safety net for push platforms like Stripe and Shopify: a full re-poll heals any webhook the provider dropped, so a missed event can never leave wrong numbers standing indefinitely. |
| 24 hours | AdSense | Google finalizes AdSense earnings one to three days after the fact — polling more often would burn API quota re-reading unchanged estimates. |
Two details worth knowing: the scan runs every 30 minutes, so a source becomes due and then syncs at the next tick — expect up to ~30 minutes on top of the cadence. And sources whose credentials are terminally dead (the red Reconnect state) are skipped entirely — retrying a revoked key every cycle can't succeed. They re-enter the schedule the moment you reconnect.
The Refresh button
The toolbar on both the workspace portfolio and every business page has a Refresh button showing how long ago the most recent successful sync happened ("32s ago", "2h ago"; hover for the exact timestamp). Clicking it force-syncs:
- On the portfolio — every source in every business of the workspace.
- On a business page — that business's sources only.
The click enqueues background sync jobs and returns immediately — the button spins while results stream back in, source by source, over the live channel. Widgets update as each source finishes; you don't wait for the slowest one. Refreshing requires the Editor role or higher.
How updates reach your screen
Three pieces, whether the trigger is a webhook, a poll, or your Refresh click:
- New data lands — a provider webhook arrives at its per-source Ploxir URL (verified, deduplicated, written to the database), or a background sync finishes with a fresh snapshot.
- The server publishes a hint— Ploxir's internal event bus fires a "your data changed" hint scoped to the workspace that owns the source.
- Your browser refreshes silently — every open dashboard tab holds a Server-Sent Events connection to
/api/events/dashboard. The hint triggers a soft React Server Components refresh: widgets re-render with new data while scroll position, open dialogs, and selection state are preserved. Bursts of hints are coalesced (~350ms debounce) so a batch of events causes one refresh, not ten.
Backgrounded tabs
To avoid burning work on tabs you aren't looking at, Ploxir pauses re-renders while a tab is hidden. The connection stays open — change hints are queued and applied the moment you switch back, so you see fresh data immediately on focus.
The reconnection supervisor
Ploxir doesn't rely on the browser's built-in EventSource retry — the browser gives up permanently on failures like a server restart mid-deploy, and machine sleep can kill the socket without ever firing an error. Instead, a supervisor owns the connection:
- If the stream dies, it reconnects with exponential backoff (1s → 30s, with jitter).
- It also retries immediately when you refocus the tab, your machine wakes from sleep, the network comes back online, or the page returns from the back/forward cache — and a watchdog detects long timer gaps (a frozen tab or a sleeping laptop) and checks the connection on recovery.
- Every successful reconnect triggers one catch-up refresh, so anything that happened while the connection was down shows up right away. Deploys are therefore invisible: the stream drops, reconnects, and catches up — no data is missed.
- If reconnection keeps failing, Ploxir probes your session once: if the server is merely unreachable it keeps retrying, but if your session has expired it stops instead of retrying a dead login forever — sign in again to resume live updates.
Reading the freshness chips
Each row on a business's Sources page shows synced <time> ago plus a real-time status chip. Hover any chip for the full explanation. The states:
| Chip | Meaning |
|---|---|
| live (pulsing green) | Credentials work, the webhook is registered with the provider, and events are arriving (or the webhook was registered within the last 24 hours and is still in its grace window). |
| webhook silent (amber) | The webhook is registered but no event has arrived in 7+ days. Either the account genuinely had no activity, or the provider silently stopped delivering. The Verifyaction on the row asks the provider directly whether the webhook still exists and is enabled — and if it's gone, flags it so the next sync re-registers it automatically. |
| api broken (red) | The most recent sync failed — the error text is shown on the row. Real-time can't work either until the credential issue is fixed. |
| webhook pending (amber) | Auto-registration hasn't run yet; it fires on the next sync. |
| webhook setup failed (red) | Auto-registration errored — the row shows "Real-time disabled:" with the provider's reason. The source keeps working via polling. |
| (no chip) | The platform has no auto-registered webhook to track — poll-only platforms and paste-a-URL receivers show no registration chip. |
Widgets never quietly show frozen data from a dead source: a source whose credentials have expired gets a red Reconnectchip on its widgets, and a deleted source's widgets are archived with it rather than rendering a stale snapshot.
What "real-time" honestly means per platform
The upstream pipeline matters as much as the delivery path:
- Stripe charge, Shopify order, custom webhook event — seconds. The event describes something that already happened; there is nothing to wait for.
- Analytics platforms (GA4, Mixpanel, Amplitude, PostHog, Plausible)— Ploxir polls every 6 hours (or on Refresh), but the number you get is whatever the provider's own reporting pipeline has processed. A Refresh can't make a provider report data it hasn't finished computing.
- AdSense — earnings are estimates that Google finalizes one to three days later. Ploxir polls daily; more frequent syncing would not produce fresher truth.
- App Store— Server Notifications (if you wire them) deliver per-purchase updates live; the Sales & Trends report that backs historical charts is finalized by Apple roughly a day after each day closes.
- Datadog / Sentry — the metric bodies (APM, errors, sessions) refresh on the 2-hour poll or on Refresh; Datadog alert events additionally push instantly via its auto-registered webhook.
What if it stops working?
If updates seem to lag:
- Open DevTools → Network → filter
events. You should see/api/events/dashboardwith typeeventsource, staying open. - Click that row → EventStream tab. You should see
: pingcomments every ~25s. If you don't, a proxy between you and Ploxir is buffering the stream — let us know. - Check the source's chip on its business's Sources page. webhook silent or api broken explains a stale tile better than any network tab. Use Verify to re-check the webhook registration, or the event history on the row to confirm events are actually arriving.
- If the provider simply hasn't fired anything, nothing will arrive — an empty account is indistinguishable from a quiet one.
FAQ
Why is my GA4 / Plausible / ads number hours old?
Those platforms have no push surface — Ploxir re-fetches them every 6 hours in the background. Click Refreshto force a fetch right now. Note that the provider's own reporting delay still applies on top.
Does the Refresh button do anything for Stripe or Shopify?
Usually not much — webhooks already keep them current, and a scheduled re-poll runs every 6 hours as a safety net. It's still useful after fixing a problem (for example right after reconnecting a source) or when you want to rule out a missed webhook without waiting for the backstop.
Whose "last synced" time does the Refresh button show?
The most recent successful sync among the sources in scope — the whole workspace on the portfolio, the business's sources on a business page. Hover the button for the exact timestamp. Note it tracks syncs, not webhook arrivals — a push source can show "synced 3h ago" while its widgets are seconds fresh, because webhook events update widgets directly without counting as a sync.
My source shows "webhook silent" — is something broken?
Maybe, maybe not. It means the webhook is registered but no event has arrived in over 7 days. On a low-activity account that's normal. To be sure, click Verify on the source row: Ploxir asks the provider whether the webhook still exists and is enabled — and if it disappeared, schedules automatic re-registration on the next sync (click Refresh to trigger one immediately).
My credentials expired. Will the next poll pick things back up?
No — once a credential is confirmed dead (revoked key, expired OAuth grant), background reconciliation stops retrying that source, and its widgets show a red Reconnect chip. Reconnect the same account from the Sources page: credentials are swapped on the same source, and every widget and its history carry over.
Do I need to keep the tab open for data to stay current?
No. Syncing and webhook ingestion happen server-side regardless of open tabs. The SSE connection only affects what you see: an open tab updates live, a hidden tab queues updates and applies them on focus, and a freshly opened tab reads the latest state immediately.
Is my browser polling the server?
No. The dashboard holds one Server-Sent Events connection and the server pushes "something changed" hints over it. On an idle dashboard the only traffic is a keep-alive comment every 25 seconds. (One narrow exception: for ~30 seconds after you click Refresh, the button re-checks a few times as a fallback in case a push is dropped.)
What happens during a Ploxir deploy — do I miss events?
No. The stream drops, the supervisor reconnects with backoff, and every reconnect triggers a catch-up refresh that re-reads the latest server state. Events that arrived while the connection was down are already in the database; the catch-up simply renders them.
Who can click Refresh?
Editors and above. Viewers see the same live-updating dashboard — pushes and scheduled polls don't depend on anyone's role — but forcing an immediate re-sync is an Editor action.
