How to Compare DeFi Network Status Pages
What to check when a transaction or application appears delayed or unavailable.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
When a transaction appears delayed or an application refuses to load, the first instinct is to look for a status page. The problem is that “a status page” is not one thing. Networks, applications, RPC providers and oracles each publish their own, and they disagree in ways that look like contradictions until you know which layer each one reports on.
Comparing them is less about finding the page with the most detail and more about reading each one at the layer it actually describes.
Establish which layer each page reports on
Four layers get collapsed into the single word “network”, and each has its own status page.
The base layer is the chain itself: block production, finality, consensus participation. Its status page answers “is the chain producing blocks”. The application layer is the protocol on top: a lending market, a decentralised exchange, a bridge. Its page answers “is this application accepting operations”. The provider layer is the infrastructure between you and the chain, usually an RPC endpoint. Its page answers “is this specific endpoint healthy”. The data layer is the oracle or indexer feeding prices and metadata. Its page answers “are the values correct and current”.
A page reporting layer two cannot tell you whether layer one is fine. When an application shows a degraded banner while the chain’s own page is green, there is no contradiction. You are reading two different systems.
Read the timestamps before the status words
Status pages publish a state, and the state is only as useful as its timestamp.
Check when the page was last updated, and check whether the reported incident is still marked as investigating, identified, or monitoring. Many pages leave a resolved banner visible long after the underlying condition ended, and readers treat a stale banner as a live outage.
A second habit pays for itself: note the time zone. Pages differ, and a page reporting in UTC against a page reporting in local time can make two events look hours apart when they are simultaneous.
Distinguish degraded from unavailable
Most status pages use a small vocabulary, and the words carry different amounts of information.
Unavailable means the component is not answering. Degraded means it is answering but slower than expected, or answering with errors alongside successes. Slow means latency has risen without errors. Maintenance is scheduled work that the team announced in advance.
These are not interchangeable for your purpose. An unavailable application means a transaction you submitted may never have reached the application at all. A degraded application means the transaction probably did arrive and may still settle. That difference decides whether you should be refreshing an explorer or checking a transaction hash.
Check the layer beneath when the layers above are green
When every application page is green but your transaction is not appearing, the answer is usually in a lower layer.
Walk down: application green, check the provider page, because you may be pointed at a degraded endpoint. Provider green, check the chain page for a finality or congestion issue. Chain green, check the data layer, because an indexer lag will hide a confirmed transaction from an explorer without touching your funds at all.
Walking down in that order costs a minute and distinguishes “my money is stuck” from “my viewer is late”, which are very different situations.
Cross-check against an independent source
A status page is a self-report from the party that runs the service. It is the most direct source and also the one with the most incentive to present a favourable picture.
Cross-check with something the operator does not control. A block explorer shows whether blocks are being produced and whether your transaction was included. An independent RPC endpoint tells you whether the chain responds for you specifically, which separates a global problem from a problem with your current connection.
When a status page says everything is operational and an independent explorer shows the chain has not advanced, trust the explorer and treat the status page as stale.
What to record
Note the time, the layer, the exact wording shown, and the page you read it on. Screenshots help, because these pages are edited in place.
If the condition persists, the record becomes the basis for a support request. Support teams ask for timestamps and layer, and a reader who supplies them gets a faster answer than one who supplies a description of a feeling.
Common mistakes
The most common mistake is reading one page and concluding the network is down. A single application page describes a single application.
The second is treating a maintenance notice as an incident. Scheduled work was announced; it changes nothing about whether your funds are safe.
The third is refreshing an application interface instead of checking a transaction hash. If a transaction was submitted, its status is decided on chain and no amount of refreshing changes it. The hash is the fact; the interface is a view.