What to do when a menu update fails before service

Two kinds of failure

Menu update failures before service usually fall into two groups. The first is a bad change: someone published a wrong price, a missing section or a description with a typo. The second is an upstream problem: a connection fails, a service is unavailable, or the menu source cannot be read at the moment you need it.

The response is different for each, but the first move is the same. Make sure guests see a correct menu right now, then deal with the cause.

Step one: protect the public menu

If a bad change has been published, roll back. Rollback returns public surfaces to the previous published version. It takes one action and does not require you to understand the cause yet.

If the problem is upstream, check what guests are seeing. With Garnsh, public surfaces keep showing the last-known-good menu when an upstream issue occurs. Last-known-good means the most recent version that was published successfully. The board stays on. The QR page loads. Nobody sees an error page at the table.

Step two: tell the team what is on display

Once the public menu is stable, tell the front of house which version guests are seeing. If you rolled back a price increase, staff should know the old price is showing tonight. If an upstream issue kept yesterday’s menu up, staff should know about any dish that changed today.

A short note at pre-shift is enough. The goal is that nobody is surprised when a guest points at the board.

Step three: find the cause without rushing

With guests protected, look at what happened. For a bad change, compare the draft that was published with the version before it. Was a price entered in the wrong field? Was a section hidden by mistake? Was the change made to the wrong location?

For an upstream issue, check freshness information to see when the source was last read successfully. Check whether your Toast access or configuration changed. Some fixes sit with your own Toast setup rather than with Garnsh.

Step four: fix at the source, then preview

Make corrections in the menu you manage in Toast, not on individual surfaces. Editing the board by hand creates a version that disagrees with everything else and will be overwritten at the next publish.

Once the source is right, open the preview. Check each affected surface and each affected location. Look at the specific items that went wrong last time.

Step five: republish at a calm moment

If service has started, consider waiting until a quieter moment to republish. A correct menu from yesterday is usually better than a rushed change in the middle of the rush. Publish when someone can watch the result on the actual surfaces.

After publishing, check the board, the QR view and the website for at least one location. Confirm the freshness information shows the new publish time.

Prevent the next one

A few habits make failures rarer and recovery calmer.

• Publish menu changes outside peak hours when you can.
• Always preview each affected location before publishing.
• Keep one named person responsible for publishing per location.
• Review freshness information at least weekly.
• Write down how to roll back, so anyone on the management team can do it.

What recovery does not cover

Last-known-good behavior keeps a correct published menu visible. It does not make the menu aware of live stock or 86 status, and it does not fix problems inside Toast itself. If an item runs out, your team still handles it in the room.