Reading a validator's uptime

Most explorers show a single uptime number per validator. It is useful, but it measures something narrower than most delegators assume.

Where the number comes from

On Cosmos SDK chains, uptime comes from the x/slashing signing info. The chain counts how many blocks the validator failed to sign inside a sliding window:

gaiad q slashing params
gaiad q slashing signing-info <consensus-pubkey>

The explorer figure is usually 1 − missed_blocks_counter / signed_blocks_window. On Cosmos Hub the window is 10,000 blocks. At around 6 seconds per block that is roughly 17 hours.

So "100% uptime" means no missed signatures in about the last day. It says nothing about last week.

Putting numbers on it

• 99.9% of a 10,000-block window is 10 missed blocks.
• 99.9% over 30 days is about 43 minutes of downtime.
• 99.98% over 90 days is about 26 minutes.
• The jail threshold on Cosmos Hub is 5% signed, so a validator can show 96% and still be nowhere near jail. It is not healthy, but it is not in danger.

When an operator quotes uptime, ask over what period and from what source. A window-based figure from an explorer and a 90-day figure from the operator's own monitoring are different measurements.

What the number hides

• Late signatures count as missed. A precommit only counts if it lands in the next block's LastCommit. A validator that signs every block but sits far from the rest of the set can still show missed blocks.
• Missed proposals are not tracked separately. When the proposer is down, the round moves on and the chain continues. Some explorers show proposal history, x/slashing does not.
• Jail history is not in the figure. A validator jailed last month and unjailed the same day can show 100% today. Check jailed_until in signing info and look for unjail transactions in the account history.
• Validator uptime is not RPC uptime. A validator can sign every block while its public API, RPC or snapshot service is down. Those are separate services with separate monitoring.
• Testnet numbers are noisy. Testnets halt, reset and upgrade often. Treat their uptime as a signal of upgrade discipline, not of infrastructure quality.

What to look at instead

• Missed blocks over a long period, not the current window.
• Jail and slashing history since the validator was created.
• How quickly the validator signed again after each chain upgrade height.
• Governance participation and commission changes over time.
• Whether the operator publishes incidents when they happen.

Uptime is a floor, not a ranking. Most active validators clear it. The difference between operators shows up in the history around it.