We show our live TPS. Here's why that's still rare.

Every Minecraft host says they're fast. Surprisingly few put the one number that proves it front and center: your server's live TPS. We built TrueTick around showing it — and around the engineering that makes it safe to show.

The incentive problem

Tick metrics (TPS and MSPT) measure what a player actually experiences. They also expose the core trick of budget hosting: selling the same CPU core to dozens of customers and hoping they don't all play at once.

A host that overcommits cores cannot put live TPS on every customer's dashboard — prime time would turn it into a wall of red. So budget dashboards tend to show CPU% and RAM bars instead, the sales page says "blazing fast NVMe", and the tick rate stays politely out of sight. (Credit where due: some hosts do surface tick data — Exaroton shows live TPS in its own panel, and Aternos exposes spark-based tick data. Showing the number and overselling the core don't mix, and that's the point.)

We made the opposite bet: if the numbers are good, show them; if showing them forces you to keep the numbers good — even better. The metric becomes the contract.

How it works on TrueTick

Nothing exotic — just plain plumbing:

• Real data from the real server. We poll every running server over RCON and read its actual tick stats — the same numbers you'd get typing /tps in the console. No estimates, no synthetic benchmarks.
• Staleness gating. A number is only shown as "live" if it's fresh. If a server stops reporting — it's starting up, hibernating, or something's wrong — the dashboard says so instead of proudly displaying a stale "20.0". An old number presented as current is just a quieter way of lying.
• Empty states that stay empty. A sleeping server shows no TPS, because a sleeping server has no TPS. We'd rather show you an empty state than a decorative one.
• A guaranteed core, enforced in code. Every active server gets a dedicated core share, and the platform refuses to start more servers than the node can actually carry. When we're full, the panel tells you we're full — creating and starting is blocked with a clear message. The scheduler won't place a server it can't give a core.

That last point matters more than the dashboard. Plenty of metrics can be displayed; the question is what the system does when the metric is about to go bad. Ours stops selling.

Why pay-per-play makes this sustainable

There's a structural reason we can afford this and flat-fee hosts struggle to: metered billing. On TrueTick you pay for the hours your server is actually awake — a sleeping server costs you nothing and costs us almost nothing. We don't need to oversell sleeping capacity to be viable, because we never charged you for sleep in the first place.

Flat-fee economics push the other way: the profit is in customers who pay monthly and barely play, and the temptation is to stack as many of them per core as possible. The lag you've felt at 8pm on cheap hosts is that temptation, realized.

Hold us to it

This post is a standing invitation: when your TrueTick server is running, open the dashboard and watch the TPS line during your busiest evening. If we ever fail to keep that number where it should be, you'll see it the moment it happens — no ticket required.

That's the whole idea. Not "trust us" — "watch us."