When a delivery menu fails to publish, first identify the exact location, menu, and sales channel involved. Then check what guests can actually see there. Do not assume the failure reached every channel, or that the previous menu is still safe to sell.
If the visible menu contains unavailable items, incorrect prices, or unsafe modifier choices, use the controls available to your restaurant to stop those items from being sold. If you cannot make the affected menu safe, pause ordering on that channel while you investigate. Record what you changed and who will restore it.
Find the affected location and channel
Start with the publish result. Note the time, the menu you tried to send, the location, the destination channel, and the exact error or status. A message that says an update failed is a starting point, not proof of what guests see.
Check the affected destination from the guest-facing menu, using the correct location and ordering method. If your restaurant has multiple locations, confirm the address before drawing conclusions. A menu at another branch does not establish whether the affected branch received the update.
Then check other destinations that were supposed to receive the same change. Your direct ordering site and each marketplace may have different results. List them separately rather than marking the whole restaurant as working or broken. If you cannot access a guest view, record that result as unknown and assign someone to check it.
Use this fault tree to choose the next action:
- No clear destination in the error: Identify which location, menu, and channel the publish attempt targeted before retrying.
- One channel shows the intended menu: Record it as confirmed for that location. Continue checking the other destinations.
- A channel shows the previous menu: Decide whether that version is safe and accurate enough to keep available. If not, remove or pause the affected sales using available controls.
- A channel shows a partial change: Check items, prices, modifiers, and availability together. A visible new item alone does not confirm the whole update.
- The guest view is unavailable or unclear: Treat the result as unknown. Ask the channel or software support team how to establish the active version.
A useful first call is to the person running the shift. Tell them which channel is affected, what guests might see, and whether staff need to decline or manually correct anything. Avoid promising guests that the new menu is live until the relevant channel is confirmed.
Compare the intended change with the visible menu
Write down the last version your team confirmed on the affected channel and the change you intended to publish. The comparison should cover more than the item name. Check the price, required and optional modifiers, availability, and any description customers need to make an informed choice.
For example, removing a sold-out side is not complete if a combo still lets guests select it. A corrected price is not complete if a modifier adds an unintended charge. If a description or modifier matters to a guest's dietary decision, staff should not guess that it is safe; remove the affected choice from sale or pause the channel until the restaurant can verify it.
Separate the menu you edited from the menu guests can order. A saved change in a back-office screen may not be the same as a published change on a destination. Record both observations and their times. If a channel displays different information, note the specific difference rather than writing only “menu wrong.”
Hypothetical example: A restaurant intended to remove a soup and add a salad at one location. Its direct ordering menu shows the intended change, but a marketplace still shows the soup and no salad. The shift lead confirms the soup cannot be served. The immediate decision is to make the soup unavailable on that marketplace if the available controls allow it; otherwise, pause that channel until the menu can be made safe. The direct ordering menu can remain available if its other items and choices are accurate.
Before selecting software, ask vendors to demonstrate how they identify the active menu for your exact channel and POS combination. Can staff see a publish result for each destination? What does an error tell them, and what must they check manually? Can an item or a whole channel be paused, and where? Ask what happens to a previously published version when an update fails. The answer may depend on the connection and setup.
Use your actual restaurant integrations list for that discussion. For example, if you use Uber Eats, ask about the Uber Eats integration at the specific location. The presence of an integration alone does not establish how a failed menu update is displayed or recovered.
Correct the cause before publishing again
Gather the evidence support needs before making repeated changes. Send the affected location and channel, the publish time, the exact status or error, the intended changes, and what the guest-facing menu shows. Include item identifiers if your system provides them. Do not include customer names, addresses, or payment details in the incident record.
Ask support which system owns the correction. The problem might require a change to the source menu, an adjustment in the destination channel, or help with the connection. Do not assume that editing the same item again will fix it. Also ask whether a retry could overwrite a manual correction or send other pending changes.
Agree on a specific recovery action and a person responsible for it. If support recommends a republish, confirm which menu and destinations it will affect, what result to expect, and how long to wait before checking. If the action fails again, preserve the new result and escalate rather than repeatedly pressing publish without understanding the outcome.
For buying decisions, ask a vendor to walk through a simulated failure and recovery using a sample menu. Set an expected result first: for example, the removed item should no longer be selectable at the named location. Record the observed result separately. The simulation should not trigger a real payment, guest message, or courier dispatch. If a vendor cannot demonstrate a particular exception, record it as a limitation and ask what staff would do instead.
Keep this check focused on publication. A separate order-flow test can establish whether an order reaches the POS and kitchen correctly, but a successful transfer does not by itself prove the menu was published accurately. Ask how the proposed connection works with your restaurant POS system and who supports each part of the route.
Verify recovery and keep a usable incident log
After the correction, check the guest-facing menu again at the affected location and channel. Inspect the changed items and related choices, not just the top of the menu. Confirm that an unavailable item cannot be selected and that an added item appears with its intended price and modifiers. If a section is still wrong, keep the relevant restriction or pause in place and reopen the issue.
Use a recovery log that gives the next shift enough context to act. The sample below continues the hypothetical soup-and-salad incident. Its statuses describe observations for that example, not a promise about any product.
| Check | Recorded result | Owner | Next decision |
|---|---|---|---|
| Direct ordering, intended change | Soup absent; salad visible | Shift lead | Keep available; recheck if menu changes |
| Marketplace, intended change | Soup visible; salad absent | Shift lead | Make soup unavailable or pause channel |
| Correction request | Support given location, time, and observed menu | Manager | Confirm correction method before retry |
| Post-correction check | Not yet observed | Manager | Verify guest view before restoring sales |
The last row matters: a support response or a successful-looking publish message is not the same as a confirmed guest view. Add the actual time and result when the manager checks it. If the soup is gone but the salad is still missing, record a partial recovery and decide whether the remaining menu is safe to sell while the issue stays open.
Once the menu is correct, restore any paused items or channel only after the responsible person checks them. Tell the shift team what changed and close the incident with the cause, correction, and any follow-up owner. If the cause is still unknown, leave that item open with a next contact and time. The log can also help you compare the handoffs described in this guide to direct POS integration and middleware.
Bring your location and channel list, a sample menu change, and these recovery questions to a Fleksa integrations discussion. Request a demo and confirm availability and the recovery process for your restaurant's location and setup.
Frequently asked questions
Should we publish the menu again immediately?
First check which destination failed and what guests can see. Confirm the correction and the effect of a retry with the responsible system or support team, especially if staff made a manual change.
Can we keep another ordering channel open?
Yes, if you have checked that channel for the correct location and its visible menu is safe and accurate. A failure on one destination does not establish the status of another.
How do we know the menu is fixed?
Check the affected guest-facing menu after the correction. Verify the changed items, prices, availability, and related modifiers, then record the result and time before restoring anything you paused.
