What “the system is down” is usually describing

Down is rarely the accurate word

Total failure is uncommon. The thing in front of the clerk is nearly always running perfectly well; what has stopped is something it depends on, several steps away, in a building neither of you will ever visit. The phrase survives because it is short and because the alternative requires explaining an architecture to a queue of people who did not come in for that.

It is a useful phrase to decode anyway, because the different failures behind it have wildly different durations. Some resolve in ninety seconds. Some will not resolve until tomorrow morning, and no amount of standing there patiently will change that.

Most counters are windows onto something else

The screen at a counter is generally a thin front end. It gathers what you say, formats it, and hands it to a service that lives elsewhere — often several services in sequence, each one owned by a different team and each with its own hours, capacity and maintenance schedule. A single transaction can easily touch an identity check, a records database, a payments network and an archive, and any of those four can be unavailable while the other three are fine.

This is why the symptoms are so oddly specific. You can be told that they can look you up but not take a payment, or take a payment but not print anything, or do everything except the one step you came in for. Those are not excuses that happen to be strangely narrow. They are an accurate description of which dependency is missing.

The overnight batch, and why mornings are peculiar

A great many institutional systems still process in batches overnight. During the day they accumulate transactions; in the small hours a job runs that applies them, recalculates balances, generates statements and hands files to other organisations. That window is when maintenance is done, because it is the only period when the data is not being changed underneath the work.

Two consequences follow, and both are visible from the customer side. Something done late in the day may not appear anywhere until the following morning, which is why the counter can insist a payment was made while another channel insists it was not. And an overrunning batch is a classic cause of a system that is unavailable at nine in the morning and perfectly healthy by eleven. Nobody broke anything. The night job simply took longer than the window allowed.

Read-only is the commonest kind of broken

When a critical dependency fails, well-designed systems do not collapse; they degrade. The usual degradation is to become read-only. Existing records can be retrieved, nothing new can be written, and the counter can answer questions while being unable to act on any of the answers.

That is the state that generates the most frustration, because from the outside it looks like everything is working. The clerk is reading your file aloud. The screen is plainly showing information. And yet the one thing you need — a change committed and confirmed — is the thing that cannot happen, because committing a change requires every downstream system to accept it and one of them is not accepting anything.

Why nobody can tell you when it will return

The person at the counter typically knows less about the outage than you would expect, and this is not evasion. Outage information moves through internal channels designed for the teams fixing it, and those teams are reluctant to publish estimates for a straightforward reason: an early wrong estimate produces a second wave of disappointed people at exactly the moment it was supposed to prevent one.

So the counter gets a status, rarely a forecast. "We are aware and working on it" really is the whole of what has been passed down. Any time given beyond that is generally a guess offered kindly, and it should be treated as such.

There is a second reason estimates are scarce, which is that most outages are diagnosed backwards. The team knows the symptom long before it knows the cause, and the cause determines the repair time almost entirely: a restart is minutes, a corrupted file being rebuilt from a backup is hours, and a third party who has not yet acknowledged the problem is open-ended. Until the cause is identified there is nothing honest to say about duration.

A better question than when

Since duration is unknowable, ask about shape instead. Is this affecting one function or all of them? Is another channel — phone, post, a different branch, the website — served by the same dependency? Can the request be lodged now and processed when the service returns, which for many organisations is a genuine option that simply is not offered unprompted?

And if a deadline is involved, ask for the attempt to be recorded with a date and time. Most organisations have a mechanism for acknowledging that you arrived on time and their machinery did not. It rarely gets volunteered, and it is much easier to obtain while you are still standing there than a fortnight later.