When a kitchen display fails, keep service moving by switching to one controlled ticket process. Assign one person to record and number incoming orders, give the kitchen a clear paper handoff, and mark each order's status as it moves. Before relying on the screen again, compare that interruption log with the orders in your systems and resolve every mismatch.
The right response depends on what failed. A dark screen may leave the register and order intake working. A network or power failure can affect several steps at once. Your kitchen display outage contingency plan should tell staff what they can still accept, who owns the handoff, and when to stop taking orders rather than guess.
Identify what failed before choosing a backup
Start with a quick check at the point of failure. Is one display dark while another device works? Is the screen on but not receiving new tickets? Can the front counter still see and enter orders? Record the time the problem began and the last ticket the kitchen can confidently identify as received.
A single device problem calls for a different response from a wider interruption. If another kitchen display is working, ask whether staff can safely use it without losing station information. If not, use the paper process. Do not assume that moving an order to another screen is possible or that every order will appear there.
A network failure can leave devices powered on but unable to exchange current information. A ticket visible on a screen may be older than the order status at the counter. During a power failure, screens, printers, registers, and network equipment may all be unavailable. Check each part of the order path rather than treating a lit screen as proof that service is connected.
Also check order intake channels. A counter employee may be able to write a guest's request on paper while staff cannot see new online orders. Name someone to check each channel that remains accessible. If a channel cannot be monitored or paused, tell the manager; do not promise that its orders are being received. Follow your provider's instructions for limiting intake where that option is available.
Set a service boundary early. For example, the manager may continue with a reduced menu if the kitchen can identify ingredients and modifiers reliably. If staff cannot capture orders accurately, communicate a pause or longer wait to guests instead of creating an unmanageable backlog. Do not assume cards can be accepted during an outage; follow your payment provider's instructions and only offer methods the restaurant can actually process.
Choose one temporary ticket workflow
Keep an outage kit near the expeditor: numbered paper tickets or a numbered log, pens, a clipboard, and a short list of roles and contact numbers. The manager assigns a ticket controller at the start of the interruption. That person records each order once and controls the handoff to the kitchen. A backup person should be named for breaks or a shift change.
For every order accepted during the interruption, write a temporary number, time, intake channel, guest name or other pickup identifier, items, quantities, modifiers, and any special handling instructions. Record the original order number too if one is available. Make payment status a separate field: paid, unpaid, or unknown. Never mark an order paid just because it has a kitchen ticket.
Use one physical master log, even if the kitchen needs a separate working copy. The controller gives the copy to the expeditor, who acknowledges receipt and directs it to the appropriate station. Keep working tickets in clearly labeled positions such as waiting, in preparation, and completed. Mark changes and cancellations on the master and tell the affected station directly; a note on a clipboard alone may arrive too late.
Verbal handoffs can help when staff are busy, but they need a written record. The sender reads the temporary number, items, quantities, and modifiers aloud. The receiver repeats them back before preparation starts. If a guest changes an order, the controller updates the master and the expeditor confirms which version the kitchen is using. Avoid giving the same order independently to two cooks.
Paper has a practical capacity limit. Decide before service how many open paper tickets the controller and expeditor can track without losing status. That number is an operating threshold, not a promise of kitchen output. When the log reaches it, slow or pause new intake until completed tickets are accounted for. A smaller team, complicated menu, or several order channels may require a lower threshold.
Use an outage worksheet to choose the response
The following example is hypothetical. A restaurant has one ticket controller, one expeditor, and a paper capacity limit of six open orders. It can see counter orders during the first scenario, but it cannot see online orders during the second. These are operating assumptions, not claims about any product.
| Situation | What staff can verify | Temporary choice | Return condition |
|---|---|---|---|
| One kitchen screen fails | Counter order entry works; no other kitchen screen is confirmed usable | Controller logs counter orders and hands paper tickets to expeditor; no more than six open paper orders | Screen is checked and every open paper ticket is matched or resolved |
| Network connection fails | Counter requests can be written down; online intake cannot be viewed | Accept only requests staff can record and fulfill; manager addresses the inaccessible online channel | Order channels are visible again and unseen orders are reviewed before normal intake resumes |
| Power fails | Staff cannot confirm register or screen status | Manager decides whether safe service is possible; otherwise pause intake | Equipment and order records are accessible and unresolved orders have an owner |
The table changes the decision based on what staff can actually see. In the first row, paper substitutes for a failed kitchen handoff. In the second, paper cannot by itself account for orders arriving through an invisible channel. In the third, the manager may need to stop accepting orders altogether.
Suppose the first scenario begins with four paper orders open. Staff can accept two more before reaching the six-order threshold. When the expeditor confirms that one has been completed and the controller records that status, there are five open orders and room for one more. The threshold depends on the status being updated; an unmarked ticket does not create capacity just because someone thinks it is finished.
Adapt the worksheet to your operation. List each intake channel, the person who monitors it, the information available during a failure, and the action to take if it cannot be monitored. Agree on a paper capacity limit with the people who will actually run the process.
Prevent duplicate preparation as systems return
Restoring a screen is not the same as restoring a reliable queue. Orders entered elsewhere may appear after the kitchen has already received a paper ticket. Keep the paper process in charge until the controller and expeditor have compared the two queues. Announce that rule to the team before anyone starts cooking from newly visible tickets.
Work through the interruption log in order. Match each paper entry to its original order number where possible. If there is no shared number, compare the channel, time, pickup identifier, items, quantities, and modifiers. Similar orders are not necessarily duplicates. When a match is uncertain, hold it for the controller to investigate rather than sending another copy to the line.
Record a clear preparation status for each order: waiting, in preparation, completed, canceled, or uncertain. For an order already completed on paper, make sure the returning display does not prompt a second preparation. For an order in progress, tell the station which ticket remains authoritative. For an order that appears only after the connection returns, verify whether it was accepted and whether the guest still expects it before adding it to the queue.
Do not assume the display can recall, reroute, cancel, or suppress a ticket. Ask the vendor how those actions work in your setup, including who has permission to perform them. If the necessary action is unavailable, use a visible manual mark and a direct verbal handoff so the kitchen knows not to cook the order twice.
Payment is a separate reconciliation. An order may be prepared but unpaid, paid but not prepared, or uncertain on both counts. Assign the manager or cashier to check the payment record and resolve uncertainty with the guest using the restaurant's normal process. Do not change a preparation status merely to make a payment record look complete.
Reconcile open tickets and practice the handover
Before returning to normal service, the controller and expeditor should make one final pass through the log and the available order records. Keep the interruption log with the shift records so the next manager can follow up on anything that remains unresolved.
- Confirm that every accepted paper order has a preparation status and an identified owner.
- Compare each paper order with the restored order records. Mark matched entries and investigate unmatched or uncertain ones.
- Review orders that appeared after access returned. Decide whether each is waiting, already handled, canceled, or needs follow-up.
- Check payment status separately and hand unresolved payment questions to the appropriate staff member.
- Have the expeditor confirm that kitchen stations know which open tickets to prepare and which not to repeat.
- Record the time normal handling resumes and brief the next shift on any remaining exceptions.
Ask vendors to demonstrate the handoff between order entry and the kitchen on the equipment and channels you plan to use. Fleksa's kitchen display system shows order details including items, quantities, and modifiers; confirm how your own setup presents and handles those details. Ask how a restaurant POS system behaves when a connection returns, and which records staff can use to reconcile orders. The related buying guide can help frame those questions across vendors.
Practice first in a vendor-supported training environment. Simulate a failed screen and a returning queue, then have staff match paper tickets to training orders and explain which ones they would prepare. The simulation must not trigger a real card payment, guest message, or courier dispatch. Afterward, observe a supervised service period to see whether roles and the paper threshold work under ordinary conditions; do not deliberately disrupt live orders to create a drill.
Next step: Write down your channel owners, paper-ticket limit, and return-to-service checks. Then compare Fleksa's KDS workflow against those operating requirements in a demonstration.
Frequently asked questions
Should a kitchen keep taking orders when a display fails?
Only if staff can capture orders accurately, communicate them to the kitchen, and stay within a manageable paper-ticket limit. Pause any intake the team cannot monitor or fulfill reliably.
How can staff prevent duplicate orders when the screen reconnects?
Keep the paper log in charge while the controller matches it to restored orders. Confirm each order's preparation status with the expeditor before treating a returning ticket as new.
What should be in a kitchen outage kit?
Keep numbered tickets or a numbered log, pens, a clipboard, role assignments, contact numbers, and a short return-to-service checklist where the shift team can find them.
