Anatomy of an outage
An outage produces two completely different experiences. From outside it is silence and a page that will not load. From inside it is usually a known problem being worked on with no good way to say so. Most of the panic that spreads during an incident comes from mistaking the first view for the whole picture.
#The asymmetry
When a clearnet service goes down there is a status page, a social account, and usually a support channel that stays up because it lives somewhere else. A hidden service has none of that by default. The channels for saying anything are the same channels that are down. That is the core of the asymmetry and it explains almost everything that follows.
It also means the absence of an announcement carries no information. On clearnet, silence during an outage is a signal, because the means to communicate exist and are not being used. Here, silence is the default state of an incident and tells you nothing about severity. People read it as a signal anyway, which is how a routine forty minute problem turns into a rumour by the evening.
#What the same event looks like from each side
| Minute zero | Outside: a page hangs. Indistinguishable from your own circuit being bad. Inside: nothing has been noticed yet. Monitoring works on intervals and the first minutes of anything are quiet on both sides. |
|---|---|
| Minutes five to twenty | Outside: retries fail, other addresses get tried, the first posts appear asking whether it is down for everyone. Inside: the problem is known and being characterised. This is the phase where nobody can say anything useful yet because the cause is not established. |
| Thirty minutes to a few hours | Outside: speculation hardens into claims. Exit scam is asserted somewhere. Fake replacement addresses start circulating. Inside: usually fixed, or clearly on the way to fixed. The gap between reality and the external narrative is at its widest right here. |
| Resolution | Outside: addresses answer again, often one before the others, which looks inconsistent from outside and is entirely normal. Inside: done, with a signed note if the event warranted one. |
The thing to take from that table is the timing of the third row. The moment when external certainty peaks is typically the moment when the actual problem is closest to being over. Anyone acting on that certainty is acting on the worst available information at the worst possible time, and the people circulating replacement addresses know it.
#Reading the shape of an outage
You cannot see inside, but the pattern of what is failing narrows things down considerably.
| One address, others fine | Path or address specific. The overwhelming majority of incidents. Switch and carry on. Nothing else is required. |
|---|---|
| All addresses, other onions fine | Something shared, either backend or the way all addresses are hosted. Genuine, usually short, occasionally hours. Waiting is the correct response. |
| All addresses, other onions also bad | Network conditions rather than the market. Affects everyone on Tor at once. Nothing to do but wait, and nothing market specific to conclude. |
| Reachable but broken after login | Application level rather than network level. Also the shape that a well built phishing page produces, so this is the one case where the correct first move is to verify rather than to retry. |
| Days of silence, no signed word anywhere | The only shape that justifies real concern. Days, not hours. Duration is the discriminator and almost nobody waits long enough before deciding. |
The first three rows account for nearly everything you will experience. The last row is rare, and the honest thing to say about it is that it does eventually happen to platforms and no amount of handbook reading prevents it. What the handbook can do is stop you from reacting to row one as though it were row five.
#What to do while it lasts
- Build a new circuit, then try another address. Two steps, under a minute, and they resolve most of what gets reported as an outage. See why mirrors slow down for why this works so often.
- Check whether other onion services are reachable. This one question separates a market problem from a Tor problem and costs nothing.
- Wait. Genuinely the highest value action during an incident. Most resolve inside a couple of hours.
- Do not go looking for a new address. Every address that surfaces during an outage, on any forum or chat, is worth nothing without a signature. This is the moment those are seeded, precisely because people are anxious and less careful.
- Do not enter anything anywhere until you have verified. If something does answer during an incident, that is when verification matters most, not least. The signing chapter covers what to actually check.
- Leave in flight orders alone. Nothing about a network outage affects an escrow contract. Panicking a dispute open is worse than waiting.
#Why announcements come late or not at all
Two reasons, one obvious and one less so. The obvious one is the channel problem already described. The less obvious one is that saying something early is often worse than saying nothing. An announcement made twenty minutes in, before the cause is understood, is a guess. If the guess is wrong it has to be corrected, and a corrected statement during an incident does more damage to confidence than the original silence did.
So the pattern tends to be silence during, then a signed note after, if the event was significant enough to warrant one. Routine incidents get no note at all, which is proportionate. An hour of one address being unreachable is not an event, it is a Tuesday. The next chapter covers how to check a note when one does appear, and how to recognise the fake ones that show up during the gap.