> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Session Replay Coverage %, PostHog > Session Replay Coverage % for PostHog stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Analytics](/nerve-centre/connectors#connectors-by-type) ## At a glance > **Session Replay Coverage %** is a session-replay gauge tracked from PostHog data. It is the ratio of replays captured to sessions observed, the single number that tells you how much of your real user behaviour you can actually watch. High coverage means almost every session is reviewable; low coverage means sampling is too aggressive or capture is broken, and any conclusions you draw from replays risk being unrepresentative. | | | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Replays captured divided by sessions observed, expressed as a percentage. | | **Sample type** | Backend API data from PostHog session and replay counts, refreshed on the standard data refresh. | | **Why it matters** | Coverage decides how trustworthy your qualitative analysis is. Below 80%, you are watching a thinning sample of behaviour and may miss the sessions that matter. | | **Reading the value** | Read the gauge band. Below 80% signals under-capture; check sampling settings and recent deploys. | | **Currency** | percent | | **Time window** | `30D vsP` | | **Alert trigger** | `<80%` | | **Sentiment key** | `ph_session_replay_coverage` | | **Roles** | owner, marketing | ## Calculation Calculated automatically from your PostHog data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example *A representative reading of **Session Replay Coverage %** for a typical merchant on PostHog.* Suppose coverage sits at 94%: of roughly 40,000 weekly sessions, about 37,600 are recorded. After a config change on 16 Jun 26 lowers the sampling rate, coverage falls to 55%, below the 80% alert. Now nearly half of all sessions are invisible, so any replay-based conclusion is drawn from a partial, possibly biased sample. Cross-reference Session Replays Captured for the raw count and Sessions for the denominator. For deeper investigation, use Vortex Mind to trace upstream causes; for natural-language exploration, ask Ask Viq. ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ----------------------------------------------------------------------------------------------- | -------------------------------------------------- | | [`ph_session_replay_count`](/nerve-centre/kpi-cards/posthog/session-replays-captured) | Session Replay sibling: the raw replay count. | | [`ph_replay_avg_duration`](/nerve-centre/kpi-cards/posthog/avg-replay-duration) | Session Replay sibling: average replay length. | | [`ph_replays_with_rage_clicks`](/nerve-centre/kpi-cards/posthog/replays-containing-rage-clicks) | Session Replay sibling: frustrated sessions. | | [`pos_sessions`](/nerve-centre/kpi-cards/posthog/sessions) | Audience sibling: total sessions, the denominator. | | [`ph_health_score`](/nerve-centre/kpi-cards/posthog/posthog-tracking-health-score) | Executive sibling: overall tracking health. | ## Reconciling against the vendor's own dashboard **Where to look in PostHog's own dashboard:** PostHog does not show this ratio directly, so reconcile from its parts: read the replay count in Session Replay and the session count in a sessions insight for the same period, then divide. The result should align with the gauge. Your configured replay sampling rate sets the ceiling on coverage. **Why the Vortex IQ value may legitimately differ:** | Reason | Direction | What to do | | ------------------------------------------------------------------------------------------- | --------- | -------------------------------------- | | **Sampling ceiling.** A sampling rate of, say, 50% caps coverage near that level by design. | Variable | Compare coverage to the sampling rate. | | **Session definition.** How sessions are counted affects the denominator. | Variable | Match the session definition. | | **Minimum duration.** Very short sessions are not recorded, lowering coverage. | Variable | Account for the duration rule. | **Cross-connector reconciliation:** complement with sibling cards in the same category for the full diagnostic picture. For divergence investigations, use Vortex Mind. ## Known limitations / merchant FAQs **Q: How often does Session Replay Coverage % update?** The card refreshes on the standard data refresh (typically every 30-60 minutes for live integrations). For real-time signals, force a manual refresh from the dashboard. **Q: Why isn't coverage 100%?** Even with capture on, replay sampling, minimum-duration rules, unsupported browsers, and ad blockers all reduce coverage. A high but sub-100% figure is normal and healthy. **Q: My coverage dropped below 80%. What first?** Check whether the replay sampling rate was lowered, whether a billing or storage quota was hit, and whether a recent deploy stopped the replay snippet from loading. Those are the usual causes. **Q: Can I customise the alert threshold?** Yes, sensitivity thresholds are configurable per profile in the Sensitivity tab. Adjust to match your business baseline rather than relying on the generic default. *** ### Tracked live in Vortex IQ Nerve Centre *Session Replay Coverage %* is one of hundreds of KPI pulses Vortex IQ tracks across PostHog and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.