Degraded Performance on Solana: What It Looks Like

A degraded period is one where Solana keeps working and stops working well. Blocks are produced, transactions settle, nothing is declared, and the experience of trading deteriorates in ways that are individually easy to dismiss. Recognising the band early is worth real money, because almost every expensive mistake in this condition comes from treating a network symptom as a bug in your own stack.

The five symptoms below arrive in roughly this order. None of them is proof on its own. Together they form a picture that is hard to mistake for anything else.

The band between healthy and halted

Discussions of network health tend to offer two states: fine, or down. Almost no time is spent in either. The interesting region is the band between them, where the cluster is doing its job with less margin than usual, and where the effect on you depends on what you are trying to do.

Degradation has no threshold that flips. It is a gradient, and a gradient does not announce itself. There is no moment at which a healthy chain becomes a degraded one, which is why the phrase you hear during these periods is always some version of "is it just me". That question is not naive. It is the correct question, and it has a procedure attached to it rather than an opinion.

The other reason the band matters is that automated systems live in it badly. A person notices that things feel wrong and slows down. A routine notices nothing, keeps its cadence, and converts a difficult hour into a long list of failed attempts and spent fees. The gap between those two behaviours is the entire argument for a written stopping rule.

Confirmations arrive later than they used to

The first thing most traders notice is waiting. A transaction that normally resolves quickly takes long enough that you look at it. Nothing has errored, the client is still waiting, and the interface offers no explanation.

Before concluding anything from this, check which commitment level you are waiting on. Solana exposes different levels of agreement about a block, and the strictest level is the default on most requests. A client that asks for the strictest promise and then complains about the wait is measuring its own configuration rather than the network. The levels and their meanings are set out in the Solana documentation, and the distinction is worth being precise about before it becomes evidence.

Once you have ruled that out, increased confirmation latency is a genuine signal. It says the path from submission to agreement is taking longer than usual, and it is the cheapest symptom to detect because you do not have to instrument anything. You already know how long your own flow normally takes.

Block production becomes uneven

Every slot has an assigned leader, and a leader that does not produce a block leaves the slot skipped. Skipped slots are a normal part of operation and appear even in untroubled conditions. What changes during a degraded period is their distribution: they cluster rather than scatter.

For a trader this matters because inclusion opportunities are not evenly spaced any more. Your transaction has a bounded lifetime measured in blocks, so a cluster of skips inside that window removes chances you were counting on without producing any error you can see. The transaction simply runs out of time in a period that contained fewer opportunities than the schedule suggested.

You do not need special tooling to notice this. Block times drifting relative to the wall clock and confirmations arriving in bursts rather than steadily are both visible from an ordinary client. Validator-side mechanics behind leader schedules and block production are documented by the maintainers of the Agave client for anyone who wants the layer beneath the symptom.

Success rate falls with fees unchanged

The third symptom is the one that costs money. Your parameters have not moved, your priority price is what it was an hour ago, and a larger share of your attempts stop landing. The instinctive response is to raise the price, and during a degraded period that response frequently does not help.

The reason is that the constraint has moved. During ordinary contention you are outbid for a resource; paying more improves your ranking in a competition. During degradation the whole path from submission to inclusion is less reliable, and a higher price does not make an unreliable path reliable. You end up paying more per attempt for a similar outcome, which is the worst of both.

The test that separates them

Try the same size on a quiet, unrelated account. If the quiet transaction lands promptly, you are contending for a specific resource and the fee lever is meaningful. If the quiet transaction is also struggling, the problem is broader than your pair and no amount of price will fix it. This test takes seconds and is the highest-value thing you can do in the first minute.

Endpoints start disagreeing with each other

Ask two independent providers for the current slot and you will normally get answers within a hair of each other. In a degraded period that gap widens, and different endpoints begin returning materially different views of where the chain is.

Disagreement is diagnostic. If one endpoint trails and the other is current, you have learned that the lagging node is behind and that switching helps. If both endpoints trail by a similar amount at the same time, you have learned something about the cluster rather than about either provider. That is exactly the distinction the whole diagnosis sequence exists to produce, and here it falls out of a two-line check.

A related and nastier version appears when an endpoint answers confidently with stale data. Nothing errors. Your balances, your pool state and your quotes are all internally consistent and belong to a moment that has passed. Anything you compute from them, including slippage tolerances, is calibrated to a chain that has moved on.

Things that never failed begin failing

The last symptom is the strangest to live through. Operations that have worked every day for months start returning errors. A simulation fails, a lookup times out, a routine request comes back with something you have never seen.

The temptation is to treat each of these as a bug and go looking for the change that caused it. During a degraded period there frequently is no change on your side, and the search is a trap: you will find something plausible, alter it, watch the condition end on its own schedule, and conclude that your alteration worked. That is how a codebase accumulates changes that were never justified.

The discipline is to write down what you saw, with a timestamp and an endpoint, and to make no permanent change while the condition is running. Anyone operating a professional Solana volume bot or any other automated flow should have this rule at the top of their runbook, because unattended systems generate exactly the kind of unexplained failure that invites a panicked fix.

Who notices a degraded period first

Degradation does not arrive for everybody at once, and knowing who feels it first tells you where to look for early warning. The people who notice earliest are the ones operating closest to a deadline: anyone whose transaction has to land inside a narrow window, anyone reacting to an event, anyone whose strategy depends on being early rather than on being right eventually.

Traders with generous deadlines and patient sizing may go through an entire degraded band without registering it as anything more than a slower afternoon. That is not luck; it is the design of their posture absorbing a condition that punishes tighter designs. It is also the reason two competent operators can describe the same hours in incompatible terms without either of them being careless.

The second group to notice are the systems with the least tolerance for ambiguity. Any flow that treats a timeout as a failure and immediately acts on that assumption will start generating unknown states early in the band, well before the failure rate becomes obvious. Those unknown states are the expensive part of degradation, and they appear before any of the symptoms that would have told you to slow down.

The practical use of this is ordering. If you run several strategies, the tightest one is your canary. When it starts producing unexplained misses while the patient ones are unaffected, you are probably at the first or second rung rather than looking at a bug, and the correct response is to widen deadlines everywhere rather than to investigate the canary.

The degradation ladder

These stages are a way of describing where you are, not a schedule. A period may stop at any rung, and it may not pass through all of them.

Slower confirmations. Everything still lands. You notice the wait, and the wait is the only thing that has changed.
Uneven pacing. Confirmations arrive in clumps. Block times drift against the clock. Inclusion opportunities become irregular.
Falling success rate. A larger share of attempts never lands, with your parameters unchanged and the fee lever unresponsive.
Divergent views. Independent endpoints disagree about the current slot, or one serves confidently stale state.
Novel failures. Operations with a long clean history start returning errors, and there is no change on your side to explain them.
Declared incident. Operators publish a notice on the official status property. At this point the condition has a name that is not yours to assign.

The value of the ladder is that it tells you what to do next rather than what is wrong. At the first two rungs, widen deadlines and carry on. At the third, stop escalating price. At the fourth, stop trusting a single endpoint for state. At the fifth, stop making changes. At the sixth, stop sending.

Why degradation is hard to declare

Operators do not declare an incident the moment somebody feels that things are slow, and that reluctance is correct rather than evasive. A declaration is a statement about the cluster, and the cluster is a distributed system whose participants have genuinely different views at any instant. Evidence has to be gathered from many operators before anything responsible can be said.

The consequence for you is a gap. There is a period during which the condition is real, your experience of it is accurate, and no official source confirms it. Filling that gap with speculation from social feeds is how people end up acting on rumours; filling it with your own recorded observations is how you end up with something to compare against the write-up when it arrives.

Official status information for the cluster is published at status.solana.com. Check it, note whether anything is declared, and note the time you checked. A negative result recorded at a specific moment is a real data point, and it is the one people forget to keep.

Degraded, congested, incident

Three conditions, three signatures, three responses. The table is the fastest way to place yourself.

Condition	Unevenness	Fee lever	Endpoint switch	Right response
Congestion	Across accounts and venues	Meaningful	Rarely helps	Smaller size, tighter compute, deliberate price
Degradation	Across time	Weak or unresponsive	Sometimes helps	Widen deadlines, record everything, change nothing
Local fault	Across your setup only	Irrelevant	Usually fixes it	Isolate the layer and repair it
Declared incident	Across everyone	Irrelevant	Does not help	Stop sending and wait for the operator notice

Notice that two of the four rows are answered by doing less rather than more. That is the part operators find hardest, because a bad session creates an urge to act and the correct action is frequently to stop acting until the picture is complete.

What to do while it is running

Everything here is designed to be done under pressure, in a few minutes, without tooling you do not already have.

Record the wall-clock time, the endpoint you are using, and the exact request that failed. Memory is not admissible evidence a day later.
Keep the signatures. A signature that exists on chain and one that does not lead to opposite conclusions, and you cannot recover them afterwards.
Run the quiet-account test before touching your fee settings, so you know whether the fee lever is even connected.
Compare two independent endpoints on one trivial request. Note whether they agree and by how much.
Check the official status property and write down the answer, including when the answer is that nothing is declared.
Widen deadlines rather than shortening them, and accept fewer attempts rather than more.
Make no permanent change to code or configuration until the condition has ended and you have read your own notes.

The last rule is the one that gets broken. A degraded period is uncomfortable, changing something feels like control, and the condition ending on its own will happily take credit for whatever you altered. Traders who resist that urge end up with a smaller, better-justified set of changes and a stack they still understand a year later.

When the period ends, the work is not finished. The notes you took are the raw material for a review that compares your timeline against whatever the operators publish, and that comparison is where a bad afternoon finally turns into a specific improvement rather than a story you tell.

Questions the desk keeps being asked

What does degraded performance mean on Solana?

It describes a period where the cluster continues to produce blocks and settle transactions, but the quality of that service falls: confirmations take longer, more attempts fail, and the same request succeeds inconsistently. It is a band rather than a state, which is why it is usually recognised in retrospect and why traders in different markets experience it to different degrees at the same moment.

How is degradation different from congestion?

Congestion is uneven across accounts. One contended pool fails while the rest of the chain behaves normally, and the constraint is competition for a specific resource. Degradation is uneven across time. The same request on the same account succeeds, then fails, then succeeds again, and the pattern does not follow which venue you are trading.

Can I tell a degraded period apart from my own problem?

Yes, by isolating one variable at a time. If a second, unrelated endpoint shows the same behaviour on the same request at the same moment, the cause is upstream of both. If it does not, the first endpoint or the path to it is the suspect. Doing this properly takes a few minutes and prevents days of misdirected work.

Why do skipped slots matter to a trader?

A skipped slot is a scheduled leader turn that produced no block. Skips shift when the next opportunity for inclusion arrives, so a transaction with a deadline has fewer chances than the schedule implies. Occasional skips are a normal feature of block production; a period where they cluster is one of the signals that something broader is happening.

Should I keep trading during a degraded period?

That is a risk decision rather than a technical one, and the answer should have been written down before the period started. What is technically true is that outcomes become less predictable, unknown states become more common, and any retry logic that cannot resolve an ambiguous outcome will do more damage in this condition than in any other.

Where do I confirm that a degraded period was real?

On the operator-published status property for the cluster, and in whatever post-incident write-up follows if one is published. Your own recorded observations are what let you match the two afterwards, which is why writing down timestamps, signatures and endpoints during the period is worth more than any analysis you attempt from memory.