What actually breaks when a restaurant POS goes down mid-service

Ask an operator what happens when the POS goes down and you will get an answer about the twenty minutes of chaos. Ask the same person a week later what it actually cost, and the answer is different: a stock count that would not reconcile, a card batch that had to be chased, and about forty covers whose tickets exist only as handwriting. The outage is the visible part. The mess it leaves behind is the expensive part, and it is the part a plan can genuinely reduce.

It is also worth being precise about what "the POS is down" means, because from the floor four quite different failures look identical — the screen is not doing what it is supposed to do — while they stop different things, last different lengths of time, and call for different responses. Treating them as one event is why the response is almost always improvised.

Four outages that look the same from the counter

The connection drops

The most common one, and the one worth being honest about first. Pacific POS is cloud-based. It needs a connection for payment authorisation and live sync, and we say plainly on the product pages that a drop is disruptive rather than invisible. Card authorisation stops, because authorisation is a conversation with somebody else's server and there is no version of that which works without a network. Order entry and kitchen routing stop with it if the terminal cannot reach the system that routes them.

The reason to state that rather than bury it is that connectivity is a site question, not a software question, and it is answerable before you buy anything. If your building's internet has never had to be reliable — and in most independent restaurants it never has, because a slow card swipe was the worst it could cause — then it is about to become load-bearing. A backup line is cheap next to one lost Friday, and it is the highest-value item on this page.

The power goes

Different failure, and a shorter list of things you can do about it. Terminals, printers, the router, and the kitchen display all stop together, and no amount of software design changes that. The useful preparation is small and boring: know which sockets matter, know whether the router shares a circuit with the fryers, and decide in advance whether you keep serving or stop. Most kitchens cannot safely run through a power cut anyway, which makes this the one outage where closing early is usually the right answer rather than the defeated one.

The payment rails have a problem

Your system is fine, your connection is fine, and cards are declining anyway because the problem sits with the processor or the acquiring bank. This one is worth distinguishing because the instinctive response — restart everything, ring the POS vendor — burns the twenty minutes in which you could have been taking cash and telling people at the door. If entry and kitchen routing still work and only authorisation is failing, you have a far better outage than it feels like: the restaurant still runs, you simply cannot take cards.

One device dies

A receipt printer, a kitchen display, a scanner, a single terminal. Not an outage at all in the systems sense, and it will still stop service if that device sat on the only path — the one kitchen printer, the one terminal at the pass. The question this failure asks is about single points, and it is answerable on a quiet afternoon: unplug each device in turn and see whether service could continue without it. Anything that cannot be worked around is a spare you should own.

The part nobody plans: getting the outage back into the system

Every outage plan people actually write covers the twenty minutes. Almost none of them cover the two hours afterwards, which is where the durable damage lives. Whatever you sold on paper is invisible to the system: stock was not decremented, the sales are absent from the day's report, cost per cover is computed against the wrong denominator, and any loyalty or account activity simply did not happen.

If those tickets are never entered, that day stays permanently wrong in every report that contains it — and because it is one day inside a month, nobody experiences it as an error. They experience it later as a stock count that will not reconcile, or as a Friday that looks inexplicably quiet in a year-on-year comparison, at which point the cause is a fortnight in the past and unrecoverable. The fix is unglamorous: paper tickets go in a designated place rather than a pocket, and somebody named in advance enters them before the next service.

Decide in advance what you will not reconstruct, too. Card transactions taken on a standalone terminal need matching against the batch, and that is worth doing properly. Free-poured drinks nobody wrote down do not, and pretending otherwise turns a two-hour job into an argument between people who are already tired. Draw the boundary while nothing is on fire.

A one-page plan, written before you need it

The plan is not a document. It is one page, laminated if you are feeling thorough, taped inside the cupboard by the till, and it answers the questions people ask at the exact moment they have stopped being able to think clearly.

1. Which failure is this? Cards declining on a working screen is not the same event as a dead terminal, and the page should say how to tell them apart in one line each.
2. Who gets called, in what order, with the numbers written down. The mobile number of the person who understands the router is not something to go looking for during a rush.
3. What the floor does meanwhile — cash only, a manual ticket format the kitchen can read at speed, and where the pads and a pen that works are kept.
4. What happens to the paper afterwards: where it goes, who enters it, and by when.

Then run it once. Pull the internet on a quiet Tuesday, work a real table through the manual flow, and time it. The first attempt is always worse than anyone expects, which is the entire argument for doing it on a Tuesday rather than discovering it on a Friday.