Reading Solana network status for yourself

Checking Solana status properly means answering two separate questions. First, has an operator declared an incident? Second, is your own path from your process to the cluster healthy at this moment? The official status property answers the first and cannot answer the second, and almost every wasted hour in this area comes from asking one source for both.

The checks below are all things you can run yourself with an ordinary client. None of them requires special access, and all of them produce evidence you can write down.

Two different questions

An incident declaration is a statement made by operators about the cluster, after evidence has been gathered from many participants. It is authoritative and it is late by construction, because responsible declarations follow confirmation rather than suspicion. If you are waiting for one before you act, you will act after the expensive part is over.

Your own path health is a statement about you. Your process, your connection, your provider, and the route between them. It is available instantly, it is specific to your situation, and no external source will ever publish it. It is also the more common cause of a bad session, which is why it should be checked first.

Both questions matter, in that order. Check your own path, form a verdict, then consult the official property to see whether a broader condition is confirmed. The reverse order biases everything that follows.

What official status can and cannot say

Cluster status and incident notices for Solana are published by the operators at status.solana.com. That is where a declaration appears, where its updates are posted, and where any post-incident material is linked when it exists.

What it can tell you: whether something is currently declared, which cluster it affects, and what the operators have said about it so far. What it cannot tell you: whether your endpoint is rate limiting you, whether your node is behind, whether the pool you are trading is saturated, or whether the failures you saw in the last ten minutes were part of anything at all.

There is also a timing property worth internalising. During the early part of a real condition, the status property will often show nothing while your experience is already bad. That gap is not a failure of the page. It is the time it takes to establish that a distributed system has a problem, and it is exactly the window in which your own recorded observations become the only evidence you will ever have of what you saw.

The signals you can pull yourself

The methods below are part of the documented JSON-RPC interface described in the Solana RPC documentation. Each answers a narrow question, and the value comes from combining them rather than from any single reading.

The two-minute check

1. Two slots, two providers. Ask both for the current slot within the same few seconds. Write both numbers down with the time.
2. Two health answers. Call the health method on each. Note any disagreement between a node's self-assessment and its slot reading.
3. Epoch position. Fetch epoch information once. Note whether you are near a boundary, because that changes what counts as strange.
4. Local fee sample. Request recent prioritization fees while passing the accounts you actually write. Chain-wide averages describe markets you are not in.
5. One trivial transaction. Send something minimal and watch it to confirmation. This is the only check that exercises submission, inclusion and confirmation together.
6. Official status, last. Record the answer and the time, including when nothing is declared.

Six observations, most of them one request each. The discipline is not in the checks; it is in writing the results down while they are in front of you, because a reading you remember later is not a reading.

Slot agreement between endpoints

A single endpoint reporting a slot tells you almost nothing, because you have no reference for whether that number is current. Two independent endpoints reporting slots within a few of each other tells you a great deal: both are following the same chain and neither is materially behind.

When they disagree by a wide margin, you have learned which one to stop using for now. When they agree with each other but both feel slow to you, the shared factor is either the cluster or something common to both paths, and the next check is the trivial confirmed transaction rather than more reading.

Use providers that are genuinely unrelated. Two endpoints from the same operator share infrastructure, and agreeing with yourself is not corroboration.

There is a subtlety in how you compare. Take both readings within the same few seconds, because slots advance continuously and a gap you introduced by asking one provider a minute after the other is not evidence of anything. Where a comparison matters, ask both at once and record the local time alongside both answers, so a sceptical reader later, including you, can see that the two samples were contemporaneous.

Where you are in the epoch

Solana groups slots into epochs, and the epoch information method reports which epoch you are in and how far through it the cluster has progressed. This is context rather than a health signal, and it is context you will want if anything looks unusual.

Near a boundary, several kinds of accounting change over. Behaviour that would be worth investigating in the middle of an epoch may be entirely expected at its edge, and knowing which side of that line you are on prevents an investigation that has no subject. The mechanics of epochs and the schedules attached to them are covered separately in this section's companion report on windows.

The reading takes one request and costs nothing. It belongs in the check for the same reason the time of day belongs in a log entry: it is the cheap context that makes everything else interpretable.

Prioritization fees as a local signal

The recent prioritization fees method accepts a list of accounts and reports fees observed in recent blocks for transactions that write them. That parameter is the whole point. Contention on Solana is a property of specific accounts, so a reading taken without passing your accounts is a chain-wide blur that will mislead you in both directions.

Read it as a competition signal, not as a price you should pay. It tells you what writers of those accounts have recently been paying, which is information about how crowded your market is. It does not tell you what will land in the next block, and treating it as a quote is how fee budgets quietly triple.

This is also where a trader and a tool tend to see different things. Anyone running a volume bot on Solana DEXs is writing several pools at once, so the correct reading is a set of local signals rather than one number, and a platform that presents a single figure for the whole chain is hiding exactly the variation that matters.

The trivial transaction test

Every other check in this report asks a node a question. The trivial transaction is the only one that exercises the whole path: building a transaction, signing it, submitting it, winning inclusion and observing a confirmation. It is the closest thing to a real answer available to you, and it takes one transaction to run.

Keep it genuinely trivial. A minimal transfer to an address you control, at an amount you would not notice losing, touching accounts nobody else is competing for. The point is to test the path rather than the market, so anything that introduces a contended account or a price contaminates the result.

Read it as a pass or fail on the whole chain of steps, then use the earlier checks to localise a failure. If the trivial transaction confirms promptly while your real trades do not, you have learned something important immediately: submission, inclusion and confirmation all work, so the problem is in what your real trades are asking for rather than in your ability to reach the network. That single observation eliminates the majority of the theories people form during a bad session.

If it does not confirm, the earlier signals tell you where to look. Endpoints disagreeing on slot points at a node. Both endpoints healthy and current with a trivial transaction still failing points upstream. And a trivial transaction that vanishes without any on-chain record points at inclusion, which is the one answer that genuinely belongs to the network rather than to you.

Run it during quiet conditions too. A confirmation time you have never measured when nothing was wrong is a number you cannot interpret when something is.

Client versions and upgrade windows

Validators run a client, and clients have releases. Asking a node for its version tells you what that one node is running; sampling several tells you whether the set is homogeneous or in the middle of a rollout. A mixed picture is the visible signature of an upgrade in progress.

This matters because it reframes odd behaviour. During a rollout, the outcome of a request can depend on which leader was producing when you sent it, and that unevenness is expected rather than pathological. Client release documentation and operational guidance are published by the maintainers of the Agave validator client, and reading a release note is often faster than debugging its effects.

Do not over-read a single sample. One node's version is one node's choice, and the useful signal is the spread rather than any individual answer.

What not to conclude

Self-service checks are powerful and easy to over-interpret. Four conclusions to avoid.

• Do not publish a rate. A difference between two numbers you sampled once is not a failure rate, a skip rate or an uptime figure. Quoting it as one manufactures a statistic that nobody can reproduce.
• Do not diagnose the cluster from one endpoint. Every reading from a single provider is a statement about that provider until a second one corroborates it.
• Do not treat a clean status page as proof you are wrong. Declarations lag, and your recorded observations remain valid evidence of what you experienced.
• Do not treat a declared incident as proof it caused your problem. Your failures may be unrelated, and the isolation sequence still applies.

The common thread is modesty about what a small number of samples can support. The checks are for making decisions, not for producing figures other people will repeat.

Turning the check into a habit

The best time to run this is when nothing is wrong. A baseline captured during ordinary conditions is what makes an abnormal reading obvious, and the single most common gap in a post-event review is that nobody knows what normal looked like for that particular setup.

• Run the full check on a quiet day and keep the results somewhere you will find them.
• Automate only the cheap parts, and run them on a slow interval that will not draw a rate limit.
• Always sample two unrelated providers, so every reading is comparative by default.
• Pass your own accounts to the fee method every time, without exception.
• Record clean results as carefully as bad ones, including the time and the endpoints used.
• Keep the trivial confirmation transaction small enough that losing it is genuinely uninteresting.
• Re-run the baseline occasionally, because your setup changes even when the chain does not.

What you end up with is a personal reference for how your stack behaves, which is something no public dashboard can give you. When conditions turn, you will not be trying to remember whether a two-slot gap between providers is normal. You will know, because you wrote it down on an afternoon when nothing was happening.

Questions the desk keeps being asked