Is it the network or me
Four layers can produce the same error on your screen: your code, your RPC endpoint, the path between you and the cluster, and the cluster itself. A test sequence that isolates one layer at a time.
Open the reportDiagnosing a Solana failure: network, endpoint or your own code
The same message on your screen can come from four different places. Your own request may be malformed or stale. Your endpoint may be rate limiting you, lagging behind the cluster, or serving a different commitment level than you assumed. The path between you and the endpoint may be dropping or delaying traffic. Or the cluster itself may be in a condition that affects everybody at once.
Guessing between those four is expensive, and the guess is almost always wrong in the same direction: people blame the layer they can change. This section replaces the guess with a sequence. Each step changes exactly one variable, produces evidence that survives being written down, and either clears a layer or convicts it.
layer 1 your code Stale blockhash, wrong commitment, malformed or oversized request
layer 2 endpoint Rate limits, lagging node, different defaults than you assumed
layer 3 path Latency and loss between you and the provider you chose
layer 4 cluster A condition that produces the same result for everyone
2 reports in this section
Separating a chain-wide condition from an endpoint fault and from a mistake in your own request. The order of checks, the evidence each one produces, and where the official status signal actually lives.
Reading network status yourself
Official status pages answer one question and your own measurements answer a different one. The signals you can pull directly, what each one means, and how to build a two-minute check you trust.
Open the reportEvidence beats intuition
A diagnosis is only finished when you can state which layer failed and point at the observation that proves it. Two endpoints failing identically at the same second is evidence. One endpoint failing while another succeeds is evidence. A feeling that the network has been bad all morning is not, and it is the single most common reason a working system gets rewritten for no reason. Write the observation down while it is in front of you, because the failure will not reproduce when you go looking for it later.
| Check | Changes one variable | Clears a layer if | Convicts a layer if |
|---|---|---|---|
| Second endpoint, same request | The provider | Second endpoint succeeds | Both fail identically at the same moment |
| Same endpoint, trivial request | The request | Trivial request succeeds | Even the trivial request fails |
| Explorer lookup by signature | Your view of the result | The signature exists and shows a reason | No record of the signature exists at all |
| Official status check | Your assumption of a cluster event | No incident is declared | An incident is open and matches your symptom |
Conditions The states the cluster can be in and what each one does to a trader: contention for block space, degraded periods where the chain runs but runs badly, and the scheduled windows around epochs and client upgrades. Open the section Response What to change while conditions are bad and what to do once they clear: sizing, fee posture, retry discipline, pausing rules, and the reading pass that turns an incident into a settings change. Open the section