Solana congestion, and what it costs

What congestion looks like

The mental model most people bring is of a network slowing down: pages loading late, everything sluggish. Solana does not present that way, which is why congestion is frequently misdiagnosed as a problem with the user's own setup.

What actually happens is that competition for inclusion in blocks intensifies. Transactions paying enough priority continue to land quickly. Transactions paying little wait behind them, and waiting is where the damage occurs, because a Solana transaction is only valid for a bounded window before its blockhash expires.

So the visible symptom is not slowness. It is a rising share of transactions that never land at all, while the ones that do land behave completely normally. From inside a script that looks like something breaking rather than like conditions changing.

Why it happens

Block space is finite and demand for it is not smooth. Three patterns account for most contested periods.

• A popular launch. Large numbers of participants competing for the same early position, all submitting at once, all willing to pay.
• Broad market movement. Everyone repositioning simultaneously, which raises baseline demand across every venue.
• Automated activity at scale. Bots reacting to the same signal produce correlated bursts rather than smooth load.

All three are event-driven, which has a useful implication: congestion is not a schedule you can plan around in advance. It is a condition you have to detect and respond to, and the response is different depending on whether you have a deadline.

What it costs you

Three separate costs, and the first two are frequently attributed to the wrong cause.

Higher fees for the same outcome. The priority level required to land reliably rises, which means every transaction costs more than it did an hour earlier for exactly the same result. The priority fee guide covers the measured distribution, and the distance between the ordinary level and the contested level is large.

A higher failure rate. Transactions that do not pay enough wait, expire and are rejected, having paid their base fee. This is the cost that hurts most because it produces nothing at all in return.

Worse execution on what does land. During volatile congested periods prices move more between quote and fill, which raises slippage failures independently of inclusion problems and produces worse fills on the transactions that succeed.

One more thing worth stating plainly: congestion is not a malfunction. It is what a network with finite capacity looks like when demand briefly exceeds it, and every chain that has ever attracted attention has experienced some version of it. The Solana-specific quirk is that the fee market is per-account rather than global, so a contested slot for one popular mint can leave the rest of the network almost entirely unaffected. That is why blanket statements about the network being down are usually wrong, and why the first diagnostic step is always to establish whether the problem is the chain as a whole or the specific market you happen to be touching.

How to tell it is happening

The most reliable indicator is your own data rather than any external dashboard, because it measures the thing you actually care about.

If failures rise while your configuration is unchanged, and the failures cluster in time rather than by venue or by swap size, that pattern is congestion rather than a setup problem. Failures concentrated on one venue point at depth; failures concentrated in a window point at conditions.

External confirmation is available too. Network throughput figures and the priority fee levels currently being paid both move visibly during contested periods, and we sample both weekly alongside the venue failure rates published on the measured data page. The useful habit is checking those before changing settings, because the alternative is tuning against a condition that will resolve itself.

The one thing worth ruling out first is infrastructure. A rate-limited endpoint produces symptoms that look identical to congestion, and the distinguishing test is whether the failures correlate with your own request rate or with the clock.

What to do during it

1. Raise priority fees if you need transactions to land now. The increment is small against the cost of one that does not.
2. Reduce swap size. Smaller orders tolerate the wider price movement that congested periods produce.
3. Slow the pace. Submitting faster into a contested network produces more failures rather than more swaps.
4. Sign late. The expiry window matters more than usual when inclusion is delayed.
5. Or simply wait. This is the option a campaign has and a race does not.

The last one deserves emphasis because it is the cheapest and the least used. A campaign spreading activity across a window has no reason to insist on any particular minute. Pausing during an expensive hour and resuming later costs nothing, avoids paying elevated fees for an elevated failure rate, and produces exactly the same result a few hours later.

There is one situation where waiting is the wrong answer and it is worth naming. If congestion is caused by activity around your own token, then the contested period is precisely the period when your campaign is most relevant, and pausing means missing the moment that justified running it. That is rare and it is real, and it is the case where paying elevated fees is straightforwardly correct. The distinction is whether the congestion is happening to you or because of you, and it is usually obvious from whether your token is the thing everyone is trading.

Planning around it

Since congestion cannot be predicted, planning means building tolerance for it rather than scheduling around it.

Budget in confirmed swaps, not attempts. A campaign that assumes every transaction lands is a campaign that will report a shortfall during any contested period.

Leave room in the window. A schedule with no slack cannot pause. One with slack can wait out an expensive hour and still finish.

Do not run against a deadline unless you have to. The moments most likely to be congested are the moments most likely to matter, and a deadline removes the option that costs nothing.

Watch the failure rate rather than the fee. The fee is the input you control; the share of transactions confirming is the output that tells you whether the input is right. The failure guide covers how to read which specific cause you are hitting, because congestion and depth produce different errors and only one of them is fixed by paying more.