Reading Solana network conditions from the chain side
Most trading complaints on Solana are described in the language of tools. The order did not fill, the bot missed the entry, the panel froze. Underneath that language there is usually a network state with a name, a mechanism and a set of things you can change.
This desk documents those states. What congestion is competing for, what a degraded period feels like before anyone declares one, which windows are scheduled in advance, and how to separate a chain-wide condition from a fault that lives entirely inside your own stack.
What this desk covers
One subject, approached from the network rather than from the tool. Everything here is about the chain you are sending into and the evidence it leaves behind.
Conditions with names
Congestion, degradation, epoch turnover and upgrade windows are different states with different signatures. Naming the state you are in is most of the work, because the response to each one is different and mixing them wastes an afternoon.
Symptom before cause
Every report starts from what appears on your screen, because that is where you start. The symptom column is written in the words traders actually use, and the cause column is written from public protocol and client documentation.
Isolation over speculation
There are four layers that can produce the same failure. A test that changes one variable at a time tells you which layer owns the problem in minutes, and it is cheaper than any theory you can form from a single failing request.
A response you can rehearse
Conditions arrive without warning, so the decisions worth making are the ones you made earlier. Sizing, deadlines, fee posture and a stopping rule belong in a document you wrote calmly, not in a judgement call you make while losing.
Featured reports
Four starting points. The first defines the head condition, the next two teach the diagnosis, and the fourth is what you do while it is still happening.
Solana network congestion
What is actually scarce during a busy period, why write contention on one account matters more than total chain load, and why a rejected transaction is more common than a slow one.
Open the reportIs it the network or me
A four-layer isolation sequence with the evidence each step produces, so a failing trade stops being a mystery and becomes a layer with an owner.
Open the reportReading network status yourself
Official status pages answer whether an incident is declared. Your own two-minute check answers whether your path to the cluster is working. You need both, in that order.
Open the reportTrading through congestion
Smaller units, explicit deadlines, an honest fee budget, retries that cannot double-spend your intent, and a written rule for when to stand down entirely.
Open the reportThree sections
Conditions describes the states. Diagnosis tells them apart from your own faults. Response is what changes while one is running and what you alter afterwards.
Conditions
Congestion, degraded periods, epochs and upgrade windows. What each state is, what produces it, and the shape it takes on a trading screen.
Open the sectionDiagnosis
Isolating the layer that owns a failure, and reading network signals yourself instead of guessing from one failed transaction and a busy timeline.
Open the sectionResponse
Working postures for bad conditions and the reading pass that turns an unpleasant session into a specific, defensible change in your settings.
Open the sectionPractical guides
The three reports people come back to, because each one answers a question that arrives at an inconvenient moment.
What degraded looks like
Between healthy and halted there is a band where blocks are produced and your trades still fail. The symptoms in the order a trader meets them.
Epochs, upgrades and windows
Which periods of unusual behaviour are scheduled, which are announced, and how to put them in your own calendar before they surprise you.
After an incident
Rebuild your own timeline first, then read the official write-up, then change exactly one thing. The order stops you from learning the wrong lesson.
When automation is the thing being blamed
Traders who run automated flows meet network conditions earlier and harder than traders who click, because a scheduled routine keeps sending while a human would have stopped to look at the screen.
The tool is not always the problem
A routine that fires steadily through a contended period will produce a run of failures that looks exactly like a broken tool. Before rewriting anything, find out whether the same window rejected everyone. Hosted platforms sit on the other side of that question, and the console referenced here is a third-party product with its own venue coverage and its own reporting.
Third-party product, opens in a new tab. This desk does not run it and does not verify its output.
Reference sources
Every claim on this site is meant to be checkable at one of these roots. They are also the only places worth trusting when you need to know what the network is doing right now, or what an operator concluded after an event.
Protocol documentation
The primary description of transactions, fees, commitment levels and the terminology used throughout these reports.
solana.com/docsValidator client documentation
How a validator is operated, what a client release changes, and the mechanics behind upgrade and restart procedures.
docs.anza.xyzCluster status
The operator-published view of whether an incident is open, and where post-incident notices are posted when one closes.
status.solana.comChain explorer
Where you confirm what happened to a specific signature, block or account instead of inferring it from a client error message.
explorer.solana.comHow this desk works
A short statement of method, because a site about conditions is only useful if you know how far it will go and where it stops.
Mechanisms, not events
Reports describe classes of incident and the mechanisms behind them. They do not narrate a particular outage, assign a date to it, or estimate how long it lasted. That reconstruction belongs to the operators who publish it, and copying it second-hand is how errors spread.
No metrics invented here
You will not find uptime percentages, failure rates or throughput figures on this site. Numbers appear only when they are published constants or arithmetic that is labelled as illustrative, and every such figure says which it is in the sentence that carries it.
Written by the desk
Pages are published under The Network Conditions Desk rather than an invented person. Corrections are made in place and the modified date moves with them. If a report says something you can disprove from the documentation, the desk would rather hear it than keep it.
Common questions
The questions that arrive most often, answered at the length they deserve rather than in one line.
What does Solana network congestion actually mean?
It means demand for a given block is higher than the block can carry, so transactions compete for inclusion rather than queue for it. Each leader produces blocks with hard limits on compute units, and requests that do not fit are not held for later by the protocol. The visible result is a transaction that never lands rather than one that lands late.
How do I know whether the network or my setup is at fault?
Run the same request against a second, unrelated endpoint and, where it is safe, against a second network such as devnet. If both endpoints fail in the same way at the same moment, the fault is upstream of you. If only one fails, the endpoint or the path to it is the suspect. The order of those checks is what the diagnosis section documents.
Where is the official Solana status information published?
Cluster status and incident notices are published by the network operators and client maintainers on their own status and documentation properties, and post-incident write-ups appear there rather than on third-party sites. This desk links to those roots and does not mirror, summarise or reconstruct their contents.
Does this site tell me if Solana is down right now?
No. Nothing published here is live. A page written on one day cannot describe the cluster on the day you read it, which is why every report ends by pointing at the operators who do publish real-time status. Treat this desk as a manual for interpreting conditions, not as an indicator of them.
Why do my transactions fail more during a busy launch?
Because activity concentrates on a small number of accounts, and write access to an account is exclusive within a block. A popular pool becomes a contended resource, so the compute budget you are competing for is narrower than the whole block. Fee posture, transaction size and retry behaviour all change what happens next.
Is a validator upgrade window the same as an outage?
No. An upgrade window is a planned period during which validators move to a new client release, and the expected effect is uneven behaviour rather than a stopped chain. Incident classes such as a cluster restart are different events with different signatures, and the reports here keep the two apart deliberately.