Network
{{ overall }}How good every link is: each machine's internet, the tunnel, the whole way a viewer's stream travels, and the media server's transcoding.
About this page
Every five minutes each machine pings Cloudflare, Google and Quad9, the VPS and GAME01, and the other end of the tunnel, and times its DNS. Every hour each one runs a small download, and the media server sends a little each way across the tunnel. Nothing heavier runs on its own.
The buttons run fuller tests: eight-second speed tests, the media server's file read, and Jellyfin's own transcodes of a 1080p film and a 4K HDR one, one, two and three at once, with its own NVENC settings and tone mapping. Test streams use the graphics card, so they wait while anybody is watching; an administrator can override that.
Your connection measures the browser you are reading this in, against media.ameribrit.net, the address the apps stream from. It is not behind Cloudflare, so the figure is the one your films arrive at.
"HD streams of headroom" counts 10 Mbps for each 1080p stream and keeps fifteen percent back, so a number here holds up on a busy evening.
{{ report.title }}
{{ report.lede }}
Your connection
{{ mine.note }}Measured by this browser against media.ameribrit.net, the address Jellyfin streams from, and against the panel through Cloudflare for comparison. About fifteen seconds, and up to 200 MB down.
The tunnel
Tunnel page →WireGuard between the VPS (10.88.0.1) and the media server (10.88.0.2). Each end reports separately; the speed tests run from the media server, both ways, to the panel's own test payload on the VPS.
Test streams
{{ streamsNote }}Jellyfin's own transcodes, started the way a client starts one and fetched as fast as they come, ten minutes into the film. "Real time" is playback seconds per second: below 1x a player runs dry. The ffmpeg figures are from Jellyfin's own log for each stream.
Every machine
The newest reading of everything each machine measures. Grey is a target that machine does not reach - GAME01 has no tunnel, and nothing tests against itself.
History
From the five-minute probes and the hourly speed tests, averaged into buckets on the longer windows; loss is the worst inside each bucket. Test streams are only ever run by hand, so their line is a few dots.
WireGuard
{{ tnOverall }}Whether the private link that carries Jellyfin from the house to the VPS is working.
About the tunnel
The link runs between the media server and the VPS. It carries Jellyfin to media.ameribrit.net, and it is the reason the media server needs no port open at the house.
When it fails it fails quietly. WireGuard has no connection to lose, so the interface stays up, the routes stay in place, and packets simply stop arriving. That is what this screen watches for.
Both ends report separately and are meant to disagree: the VPS knows the media server’s address because the media server dials out, and the media server does not know its own. The byte counters count from when the interface last came up, not from the last handshake.
A handshake older than about three minutes means the link is gone, whatever the interface says.
deploy/abp-wireguard.sh.{{ e.name }}
{{ e.iface }} readWho's connected
{{ mcNote }}Every client that reached Jellyfin through the tunnel in the last {{ mcWindow }}. What anyone watched is not recorded here.
About this count
This is the number the port forward at the house is waiting on: once everybody arrives this way rather than straight at the house, it can be closed and the home address stops being published.
Counted from the VPS access log, one minute behind at worst. Clients sharing an address and a browser merge into one, so this errs low; it will never make the old way in look emptier than it is.
media.ameribrit.net to count.Public status page
status.ameribrit.net ↗What family and friends read when they want to know whether something is down.
About the status page
Everything here is shown to people outside the household, so it is written for them: notices and maintenance notes appear on the page exactly as typed.
Keeping an incident off the page removes it from the incident list, the thirty-day strips and the uptime figures, and stops any Discord post about it. It stays in the panel's own history, and it can be put back.
Inside a maintenance window, what goes wrong with the services it names does not count against them and is not posted to Discord. The panel's own alerts still go out as usual.
Notices
{{ noticeCount }}A short message at the top of the page. Info reads in navy, a warning in red.
Planned maintenance
{{ windowCount }}Announced on the page beforehand as planned and during it as in progress. Up to a week long, up to 90 days ahead.
Incidents
{{ incidentCount }}Everything from the last 30 days that the page could show. "Keep off" marks one as ours - work on the rack rather than an outage anybody needed to hear about.
Discord posts
{{ discordLine }}