Network Congestion Indicators and What Each One Measures

2026-09-03

Congestion is not a number a chain publishes. It is a condition you infer from several readings, and each of them measures something slightly different and arrives at a different moment. The base fee, block fullness, the size of the queue, the tips people are actually paying, and the delay between broadcast and inclusion do not say the same thing, and when they disagree the disagreement is the useful part.

Network Congestion Indicators and What Each One Measures: key points at a glance

What a congestion indicator actually measures

Congestion is a mismatch: more demand for block space than the next block can hold. Capacity on that side of the mismatch is the chain's throughput, and nothing on chain reports the mismatch itself. What gets reported is a set of side effects, and every gauge you can open in a wallet or a block explorer is one of those side effects rather than the condition.

That distinction decides how you read a screen. A gauge computed from a block already produced tells you what the network was. A gauge computed from the queue tells you what the network is being asked for. A gauge computed from your own transaction tells you what the network did to you, and it can only be read after the fact. Treating the three as interchangeable is what turns a reading into a wrong expectation.

The base fee is the protocol reading its own last block

On Ethereum the base fee is not an estimate produced by a third party. The protocol computes it from the block before, which makes it the one congestion reading the network publishes about itself.

EIP-1559 fixes how far it can move. The gas target is the block gas limit divided by the elasticity multiplier, and with that multiplier set to two the target sits at 50% of the limit. The specification puts the rule plainly: when the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly.

The step is bounded. With the maximum change denominator set to eight, one block can move the base fee by at most 12.5%. That bound is what makes the reading legible, because the fee cannot jump: a high base fee means demand has been above target across a run of blocks rather than in one unusual moment. Six consecutive blocks at the ceiling lift it by about 103%, so even a doubling takes a handful of blocks.

The same bound is the base fee's weakness as a forecast. It always describes blocks that have already been produced. If demand collapses right now, the base fee is still carrying the pressure from before and will take several blocks to walk back down.

Block fullness is the input, and it turns first

Gas used against the gas target is the quantity the base fee is derived from, which means it moves before the price does. A block that comes in above target has already committed the next base fee to rise, and a block below target has already committed it to fall.

Reading fullness rather than price buys you about one block of warning, and it separates two situations that a fee chart draws identically. A chain sitting at target with a flat fee is in equilibrium. A chain sitting at the ceiling with a flat fee has demand pressing against the limit and a fee that is still on its way up.

Fullness has a blind spot worth naming. A block can be filled by cheap transactions when nobody outbids them, so fullness says the space was used, not that it was contested.

The mempool backlog is the queue you can see

The mempool holds transactions that have been broadcast and not yet included, and its size is a demand reading you can take before the next block exists.

Count it in gas rather than in transactions. A queue of plain transfers and a queue of contract calls can carry the same transaction count while occupying very different amounts of block space, and only the gas figure divides cleanly into what a block can clear. Expressed that way the backlog becomes a depth: a queue holding four blocks' worth of gas priced above your fee means roughly four blocks of waiting, assuming nothing better paid arrives meanwhile.

Two caveats bound this reading. Each node keeps its own mempool under its own eviction rules, so the figure on any one dashboard is that node's view and not a global total. And transactions routed through private orderflow never enter a public mempool at all, which makes the public queue a floor on demand rather than a measurement of it.

Priority fees separate a busy network from a contested one

The base fee is the entry price everyone in the block pays. The priority fee is what senders added on top to be sorted ahead of each other, so the spread between low and high tips in recent blocks is the competition reading.

A narrow spread under a high base fee describes sustained but unhurried demand: space is expensive, and nobody is fighting for position inside the block. A wide spread describes an auction, which is the pattern around a mint, a liquidation cascade, or any event where landing in this block rather than the next one carries value.

The practical consequence is about which number to raise. When the spread is narrow, a larger tip buys little, because you were not losing a contest. When it is wide, the tip is the only lever you hold, since the base fee is identical for every transaction in the block.

Confirmation delay is the reading that arrives last

Time from broadcast to inclusion is the outcome every other gauge stands in for, and it is the only one that measures your experience instead of the network's state. It is also the slowest to arrive, because you cannot read it until the transaction has landed.

Its diagnostic value lies in disagreement with the others. If fees are ordinary and your transaction is still waiting, congestion is not the explanation and the problem is on your side: a fee below the current base fee, or an earlier transaction from the same account blocking the sequence, will leave you stuck on a network that is not busy at all.

Layer two sits on a fee market of its own

A rollup posts its data to Ethereum in blobs, and EIP-4844 defines blob gas as a new type of gas, independent of normal gas and following its own targeting rule. Independent is the operative word: the blob base fee is computed from blob demand alone.

So the base layer and the rollups can be congested at different times, and a calm gauge on one side certifies nothing on the other. A quiet execution-gas reading says nothing about whether blob space is contested, and a rollup's own sequencer can be backed up while both fee markets look cheap.

The gauges side by side

Each row answers a different question, which is why no single one of them is the congestion number.

Reading	What it measures	What it cannot tell you
Base fee	Pressure across recent blocks, published by the protocol	What the current block is being asked for
Block fullness	Space used against the target, one step ahead of the fee	Whether that space was contested
Mempool backlog	Demand waiting, best counted in gas	Anything routed privately
Priority fee spread	Competition for position inside a block	The entry price, which the base fee sets
Confirmation delay	Your own outcome	Anything at all until after it happens
Blob base fee	Pressure on rollup data space	Conditions on execution gas

The bottom line

Congestion is inferred, never reported. The base fee is the protocol's own bounded summary of blocks already built, block fullness is the input that turns one step earlier, the mempool is the visible part of the queue, the tip spread is the contest inside the block, and confirmation delay is the result you personally got.

Read them as a set and check the timestamp on each one before acting. The recurring mistake is asking a backward-looking gauge to forecast the next block, and the recurring fix is to pair it with the queue in front of it. To keep learning the fundamentals, follow more from Bitbase Academy.