Failure signatures.
Specific failure signatures operators search for, each explained directly and routed to the mechanism research and evidence behind it.
Cross-chain bridge transfer stuck pending source finality: what is actually waiting
A bridge transfer stuck pending source finality is waiting for the source chain to make the deposit irreversible, because the bridge cannot safely mint or release on the destination until reorganisation risk is gone. The delay is a property of the source chain's health, not of the bridge contract.
Different blockhash across RPC endpoints and stale getAccountInfo responses: why nodes disagree
Two Solana RPC endpoints returning different blockhashes are not malfunctioning: each node answers from its own replay position, and there is no single RPC view of the chain. Stale getAccountInfo responses come from the same place, a node that is behind the tip but still answering.
Solana confirmation times slow under load: where Turbine propagation delay comes from
When Solana confirmation times stretch under load, the delay usually accumulates in propagation and voting rather than in block production: blocks still arrive on time, but shreds take longer to fan out through Turbine and votes land later, so the supermajority that defines confirmation forms more slowly.
Solana RPC reads available but writes failing: why the two paths fail separately
Solana RPC reads and writes travel different paths with different failure domains: reads are served from the node's local state, while a write must cross the network to current leaders and survive their ingress policy. Under partial degradation the write path fails first while reads look healthy.
Solana RPC returning "429 Too Many Requests" and getProgramAccounts timing out: what it means
A 429 from a Solana RPC endpoint is the provider shedding your traffic before the node does expensive work, and a getProgramAccounts timeout is the node failing to finish that work in time. Both are symptoms of the same cost asymmetry: some RPC methods are orders of magnitude more expensive to serve than to send.
Solana transaction dropped before reaching the leader: QUIC stake-weighted throttling explained
Solana has no mempool, so a transaction that is dropped before the leader is not queued anywhere and will simply expire. Under load, leaders apply stake-weighted quality of service at QUIC ingress: connections backed by stake get capacity in proportion to it, and traffic from unstaked nodes is the first to be shed.
Solana validator slot distance increasing and vote credits dropping: what it means
A growing slot distance means your validator is processing blocks more slowly than the cluster is producing them, and dropping vote credits are the financial trace of the same lag: votes that land late earn fewer credits. The cause is almost always local resource saturation, not the cluster.
Solana validator stuck catching up and snapshot download slow: why it happens
A validator stuck catching up is losing a race: it must replay slots faster than the cluster produces them, from a snapshot that is ageing while it downloads. If the snapshot peer is slow or replay is disk-bound, the gap never closes and catchup reports the node falling further behind.
Validator packet loss, AF_XDP drops and IOPS saturation: reading host-level saturation signals
Rising packet loss, AF_XDP drop counters and disk IOPS saturation on a validator host are three readings of the same condition: ingest and storage are running past the capacity the pipeline behind them can drain. Each one moves the node closer to falling behind the chain.
Why is my Solana transaction not confirming? "Blockhash not found" and "block height exceeded" explained
A Solana transaction that never confirms has almost always either expired before it reached a leader or was dropped at ingress. Solana has no mempool, so a transaction that does not land within the lifetime of its recent blockhash is simply gone.