Tor-network-level health affects every onion service, including Nexus Market. Where to read the network-side signal and how it relates to the platform probe on this site.
Tor network status is published by the Tor Project at the metrics portal. Network-level events that affect this platform's reachability include guard-relay rotations, directory-authority outages, and broad bandwidth shifts. None of these are platform-side issues; they affect every onion service on the network simultaneously.
The probe on this site cannot distinguish a Tor-network-side congestion event from a platform-side latency event without cross-referencing Tor metrics. When the probe shows broad latency elevation across all three mirrors simultaneously, the most likely cause is network-side; when only one mirror is elevated, the cause is platform-side or guard-pool-specific.
Directory lookup finds where the service lives. Your circuit is built. An introduction is arranged through a relay the service nominated. Both sides meet at a rendezvous relay. Then the service itself answers. Each stage fails differently and each produces a recognisable symptom.
There is no single server whose state describes the service. There is a set of relays between you and it, chosen freshly, and any of them can be the reason. Two people can honestly disagree about whether a service is up at the same moment and both be right.
A lookup failure ends quickly with a not found error. A circuit or introduction problem takes thirty to sixty seconds and then errors. A rendezvous problem is a long silence with no error at all. Load at the far end is a page that eventually arrives, slowly.
Any probe measures its own path. Publishing that as a global truth is the compromise every status page makes, and knowing it is a compromise is the difference between using such a page well and being misled by it.
Component states, the 90 day uptime history and the incident log live on the status dashboard. This page covers one question in depth rather than repeating the board.