How to get Swiggy to put your restaurant back online
Restaurant operators on Swiggy are usually waiting on a queue rather than looking for a switch. Three different holds produce an outlet that cannot be ordered from, and each ends in a different way. An outlet that was never taken live needs a Ready To Go Live trigger pressed inside the Swiggy account. An outlet awaiting mapping waits on the Swiggy team, offline, on a weekday. And an outlet whose menu failed a quality check has its publishing frozen until the errors are fixed. None of the three announces itself, and none is undone by a status control.
On Swiggy the return is a queue rather than a button
That is the structural fact to plan around, and it follows from how little Swiggy puts in front of partners. No partner reference is readable without an account, so the material that describes a recovery was written by integrators rather than by the platform, and UrbanPiper publishes eight articles about this channel.
The single sentence that shapes every recovery on this platform is UrbanPiper’s description of how an outlet is attached: the mapping “is carried out offline, with assistance from the Swiggy team”. Source: help.urbanpiper.com.
Offline means people, and people mean a calendar. UrbanPiper records that activation runs “from Monday to Friday” and that an outlet “is expected to be live within 48 hours”. A brand that opens a branch on a Friday and expects it to sell on Saturday has misread the working week rather than lost an outlet, and a brand that waits three hours before escalating is escalating far too early.
RTGL is the action that makes an outlet sellable, and you press it
The abbreviation is Swiggy’s own and it is the closest thing this platform has to a reopen. UrbanPiper documents the failure string an unmapped outlet returns, “Given restaurant is not correct”, explains it as the store not being integrated yet, and gives one instruction: “Trigger RTGL (Ready To Go Live) from your end.” Source: help.urbanpiper.com.
The words “from your end” place the control in the merchant’s own Swiggy account rather than in any integrator, which is the opposite of what an operator assumes when an integrator is reporting the error. A team that raises a ticket with its middleware vendor for this error is asking the wrong party.
The same flow has a named button on the integrator side, described as a “Request to Go Live” action where the aggregator is chosen and its “Platform ID” entered. Two actions, two systems, one outlet, and both have to happen. Recording which of the two was completed and when is the difference between a clean escalation and a conversation that starts from scratch.
What Swiggy asks for before the team will map an outlet
Two identifiers, and getting them exactly right removes most of the delay. UrbanPiper lists what to have ready: the “Outlet/Restaurant ID(s)” and the “Outlet URL exactly as listed on Swiggy”, with a precondition that outlets “exist in Swiggy Merchant and are eligible for online ordering”.
The word exactly is doing real work in the second one. An outlet URL retyped from memory, or copied from a customer share link with tracking parameters attached, is a different string, and a mapping request built on it goes back and forth for a day before anybody notices.
Keeping those two values on file per branch, alongside the platform identifier used by the integrator, converts a mapping request from a research task into a form fill. For a chain that opens branches regularly this is the single highest value list to maintain, because it is needed at exactly the moment nobody has time to assemble it.
A menu quality hold has to be cleared before any update reaches the outlet
This is the hold that most operators do not know exists, and it locks the outlet’s menu rather than its status. UrbanPiper documents that “Swiggy conducts a Menu Quality Check (QC) on all published menus” and describes a failure in two parts: “Any items failing QC standards are removed from the menu by Swiggy, and menu publishing will be on hold until all errors are fixed”, followed by “All subsequent menu updates for the outlet will be applied only after passing QC”. Source: help.urbanpiper.com.
So the return here is a correction, not a request. Until the named errors are fixed nothing a brand publishes will reach that outlet, including the fix for whatever else is wrong with it. That is why an outlet can appear frozen in an old state while the brand is confident it has pushed three updates.
The checks are ordinary formatting rules, which makes them cheap to satisfy once and expensive to ignore. The published requirements include “Title Case” for item, category, subcategory and modifier names, “Sentence Case” for descriptions, connecting words in lowercase, and a requirement that “all category, sub-category, and item names are unique”. Correct them across the whole brand rather than at the outlet that failed, because a rule broken once is normally broken in the same place everywhere, and the check runs on each location on its own.
When to wait rather than retry on Swiggy
There is one documented case where retrying makes the wait longer, and Swiggy gives the number. UrbanPiper’s error table records “Target server error” with the cause “Menu push is queued up due to multiple pushes or server lag at Swiggy.” and the instruction “Wait for up to 4 hours before publishing the menu again.”
Four hours is longer than most people’s patience and the alternative is worse, because each additional push extends the queue that is already the problem. A team that pushes every fifteen minutes during an incident is manufacturing the condition it is trying to escape.
Two other Swiggy timings are worth holding separately so they do not get confused with this one. Menu updates in normal conditions are described as taking “up to 5-10 minutes to appear on the UI”, and outlet activation is the 48 hour figure above. Three numbers, three meanings, and mixing them is how a brand concludes a platform is broken when it is merely slow in a documented way.
Who signs off Swiggy exceptions, and what should a chain keep on file?
A named Swiggy contact rather than a support queue, at least for the exception UrbanPiper documents. On packaging charges outside the published slab, the instruction is direct: “If you want to set a packaging charge outside the allowed slab, you must get prior approval from your Swiggy POC (Point of Contact). Without Packaging charge approval, your menu update will be rejected.”
That is the shape of authority on this platform generally. Mapping happens with the Swiggy team, exceptions go through a point of contact, and neither has a published response time. A brand that knows the name of its point of contact before an incident recovers faster than one that starts looking during it.
What to keep on file per outlet follows from everything above: the Swiggy outlet identifier, the outlet URL exactly as listed, whether RTGL has ever been triggered, the date of the last successful menu publish, and the name of the point of contact. Assemble it while nothing is wrong. Every entry on that list is cheap to look up on an ordinary Tuesday and expensive to look up while a branch is dark and a manager is on the phone.
The other half of a return here is knowing when it finished, and on Swiggy nobody will say. All three holds end in silence, so a chain that raised a mapping request or cleared a quality check has to go and look at the outlet to find out whether the work landed, and the gap between the two is invisible from the inside. Kitchain (kitchain.co) supplies that half by reading the Swiggy outlet page itself, which turns a return from a ticket somebody filed into a time somebody can quote.