← User guide · API · Testing · Statistics
Every statistic this system shows you, what it actually measures, and what it means when it looks wrong. Written to be read next to the screen it describes.
| Page | Answers | Who sees it |
|---|---|---|
| Analytics (per channel) | How is this one channel doing right now, and how did it do today? | The customer who owns it |
| Admin → All customers | How much is this whole server doing, and which account is responsible? | Operator |
| Admin → Business metrics | How much money is this making, and is it growing? | Operator |
They will not add up to each other, and that is correct: they count different things over different windows. The commonest confusion on this page is expecting "viewers now" and "unique viewers today" to be related. They are not.
| Number | What it counts | When it looks wrong |
|---|---|---|
| Viewers now | Distinct players that fetched a segment in the last ~30 seconds. A player that stops asking drops out within about a minute. | Higher than you expect: one person with the page open in two tabs is two viewers, because it is two players fetching. Slow to fall: that is the window closing, not a stuck count — wait a minute. |
| Peak | The highest "viewers now" seen since the channel went on air. Resets when the broadcast ends. | Peak far above the current figure is normal for a programme that has finished; it is the high-water mark, not an average. |
| Egress now | Bytes leaving this server for this channel, over the last few seconds, expressed as a rate. | Roughly viewers × bitrate. If it is far below that, viewers are being served by a CDN or edge in front of you and this server never sent those bytes. If it is far above, something is downloading rather than watching. |
| Requests | Playlist and segment requests served since boot. | Large numbers are normal: a player asks for a playlist every few seconds plus a segment. Ten thousand requests is a handful of viewers over an hour. |
| Data served (3h) | Bytes sent for this channel over a rolling three hours. | This is the figure to compare against a bandwidth bill, not "egress now". |
| Live renditions | How many bitrates are currently being published or produced. One means a single stream and no ABR. | If you push _1080p, _720p and _480p and this says 1, only
one is arriving — check the labelled keys. |
| Unique viewers today | Distinct viewers seen since 00:00 UTC. Distinct means a different viewer identity, not a different request. | UTC, not your timezone — it resets at midnight UTC, which may be the middle of your afternoon. Somebody who watches morning and evening counts once. |
| Watch time today | Viewer-minutes: two people for thirty minutes is one hour. | The honest measure of whether anyone is actually watching. Viewers with a tiny watch time means people arrive and leave — usually a startup or quality problem, and the QoE panel will say which. |
| Avg session | Watch time divided by sessions, including sessions still running. | A very short average on a long programme means people are not staying. Read it with the stall figures below. |
| Egress today | Total bytes sent for this channel since 00:00 UTC. | The number that maps to what you are billed for by your host. |
Everything above is measured at this server: what it sent. Quality is measured at the player, which is the only place that knows whether the picture actually appeared. Players post short beacons; nothing is guessed.
| Number | Meaning | What is normal |
|---|---|---|
| Startup time | Press play → first frame. | Under 2s is good, 2–4s is noticeable, over 5s is where people leave. Low latency shortens it; a long DVR window does not affect it. |
| Stalls / stall seconds | Times playback froze to rebuffer, and how long in total. | Occasional stalls on mobile are normal. Stalls concentrated on one rendition mean that rendition's bitrate is too high for the viewers receiving it — the per-rendition table tells you which. |
| Rebuffer % | Share of watch time spent frozen. | Under 0.5% is healthy. Over 2% is a bad experience even if the stream never drops. |
| Fatals | Playback gave up entirely. | Should be near zero. A cluster of fatals right after a change is the change. |
The same traffic questions, for the whole server, attributed by channel owner — a fact this server knows — rather than anything a viewer sends.
| Column | Meaning |
|---|---|
| Channels / Live | How many that account has, and how many have something publishing right now. Live is the number that costs you bandwidth; channels is just how many exist. |
| Viewers now / Egress | Current, across that account's channels. |
| Watch hrs today / Unique today | Since 00:00 UTC. |
Sorted busiest first, because the question is nearly always "who is using this box". An account with channels and no traffic is not broken; it is idle.
dev, and every figure on this page counts money that never moved. Health
says so, and the invoice list shows dev against each one.
| Number | How it is computed | Watch out for |
|---|---|---|
| MRR | Sum of the plan price of every active or past-due subscription. | Past-due is included deliberately: the customer has not cancelled and the provider is usually retrying. It is what you expect to bill, not what has cleared. |
| Revenue · 30 days | Paid invoices minus refunds in the window. | This is cash recorded in ssh101's ledger. A refund issued at your provider and not recorded here will not appear. |
| Revenue · all time | The whole ledger. | Starts from when this server started keeping one — not from when your business started. |
| Paying customers | Accounts on a paid plan, active or past-due. | An account you comped to Business counts here and contributes MRR it will never pay. Comps distort this more than anything else. |
| ARPU | MRR ÷ paying customers. | Meaningless below about ten customers; one Business account makes it look like your average. |
| Churn · 30 days | Cancellations in the window, from the audit log. | Event-derived and noisy while the base is small — one cancellation out of three customers is 33%. |
| Funnel | Signed up → verified → created a channel → streamed → paying. | The most useful thing here. A big drop between "created a channel" and "streamed" means people cannot get their encoder connected, which is a documentation problem, not a demand problem. |
| Watch time · 7 days | Peak concurrency × minutes. | Explicitly an upper bound, not a measurement — it assumes everyone present at the peak stayed for the whole minute. Use it for trend, not for billing. |
| Viewers by country | From the GeoIP database. | Empty until a GeoLite2 database is installed. Not an error. |
| Symptom | Usual cause |
|---|---|
| Viewers 0 while you are watching | You are watching through a CDN or edge cache; this server served the segment once and your player is not coming back to it. |
| All QoE blank | No web players have reported yet — native apps and VLC do not send beacons. Open the embed page once and it will populate. |
| Watch time 0 with viewers > 0 | Sessions are open but have not accumulated a minute yet. Wait. |
| Analytics empty as operator | The per-channel page is scoped to channels you own, and an operator usually owns none. Admin → All customers is the operator's view. |
| Business metrics all zero | No paid subscriptions yet, or checkout is still in dev mode. |
| Country map empty | No GeoIP database installed. |
Per-minute history, QoE series and the invoice ledger are written to disk and reload. Live counters — viewers now, peak, requests since boot — start again from zero, which is correct: they describe the running process, not the business. If everything is empty after a restart, check the Database row on Health: an in-memory store loses accounts, channels and invoices entirely.