How to get DoorDash to put your restaurant back online
Restaurant operators on DoorDash are not asking a person to switch a store back on, they are asking a system to accept a reactivation, and it can refuse. DoorDash publishes three conditions that make a reactivation fail outright: banking information that is not present, banking information that is invalid, and no active point of sale menus at the store. Each one blocks the store from returning for reasons that have nothing to do with the kitchen. Underneath that sits a default nobody expects, since a deactivation sent without an end date runs for two weeks.
Which DoorDash surface should you use to bring a store back?
Whichever one is closest to a person who knows the store is off, because DoorDash offers three and they are equivalent in effect. The tablet running the Order Manager application carries a store status control in the branch. The Merchant Portal holds a store availability section for the same job from a desk. The Business Manager application covers the same ground from a phone.
The one that matters operationally is the tablet, and not because it is better. DoorDash’s most common automatic pause is triggered by the tablet itself, described in a single sentence: “Tablet Heartbeat is a tracking system. It automatically pauses your store if your DoorDash Tablet can’t receive orders for five minutes or longer.” Source: help.doordash.com. A pause caused by a tablet that lost power or dropped off the network will not be cleared from that tablet until the tablet is working again, so the physical fix comes first and the status action second.
For a chain the useful conclusion is about staffing rather than software. Every branch needs one person who can reach the device and one account with Merchant Portal access, because a store paused by a flat battery at 18:00 is a store that stays paused until somebody performs both halves of the repair.
What to do when DoorDash returns an error instead of reactivating
Stop pressing and read the string, because DoorDash names each blocker precisely. Its developer documentation lists the conditions that make a reactivation request fail: “Store banking information is not present”, “Store banking information is invalid”, and “No active POS menus exists at the store”. Each of the three is described as blocking the request until the condition behind it is put right, so a retry on its own changes nothing. Source: developer.doordash.com.
Two of the three are finance department problems and one is a menu problem, and none of them will be solved by anybody standing in the restaurant. A banking record that lapsed after a change of entity, a bank account replaced during a refinancing, a menu that was archived during a rebrand: each of those turns a five minute outage into a multi day one, because the pause happens instantly and the repair goes through a queue in another building.
The order of work follows from that. Confirm which of the three is failing, route it to the function that owns it, and only then retry the reactivation. Retrying first wastes the hour in which somebody could have been fixing the actual blocker, and it produces the most misleading incident note available, which is that DoorDash would not let us reopen.
How long does a DoorDash pause last if nobody touches it?
Longer than almost anyone assumes, and the number is published. DoorDash writes: “If no end date is specified in the deactivation request, the store will only be deactivated for two weeks and will automatically reactivate after that period has passed.” The same documentation warns integrators that where both an end time and a duration are supplied, the platform applies its own fourteen day default rather than the values sent.
Fourteen days is a floor under the damage, not a way out of it. A store missing for that long has not had an outage, it has had a gap in its trading history, and the automatic lift arrives long after anyone would have wanted it. The practical rule for anyone building against the API is to always send an explicit end date, because the alternative is not indefinite, it is fourteen days, which is worse in the specific sense that nobody notices it is happening.
Pauses applied by the platform behave differently, and the difference matters when planning a response. Their webhook payload carries a start and an end, so the state is bounded from the moment it is created. Whether that end will arrive on its own or only after a repair is not something the payload settles, because the reasons behind platform pauses are not published as a list a partner can look values up in. Treat the end time as a deadline for fixing the cause rather than as a promise.
Reactivating a store does not repair the thing that paused it
This is the trap specific to DoorDash, because most of its pauses are consequences rather than decisions. The published causes include “Avoidable wait times: Orders consistently take longer than expected”, “Avoidable cancellations: Orders are canceled for reasons within your control”, and “Missing or incorrect items: Fulfillment accuracy drops”, alongside cases where the tablet or the point of sale is not receiving orders correctly.
A store reactivated while the delays that paused it are still happening is a store that will be paused again before the service ends. The reactivation is free and the underlying condition is not, so the recovery that actually holds is the one that changes the input, whether that is opening a second prep station, extending quoted preparation times, or taking a busy branch off a promotion for the night.
The same applies to integration faults, where DoorDash says a store may be paused “when orders fail to reach your POS”. An order the integration rejected or never confirmed counts as failed. Pressing reactivate on a store whose integration is still dropping orders restores the listing and restores the fault at the same time.
What DoorDash tells an integrated brand at the moment of a pause
More than most platforms, and it is the difference between a recovery measured in minutes and one measured in shifts. DoorDash publishes a webhook typed as “Store Temporarily Deactivated” and describes the range of causes it covers, saying stores “can be temporarily deactivated for a variety of reasons, spanning from self pausing via Merchant Portal to being automatically temporarily deactivated for quality reasons”. Source: developer.doordash.com.
Deactivations sent by an integration carry a reason chosen from six fixed values, listed on why a DoorDash store shows as temporarily deactivated. For recovery work the useful property is that they are machine readable. A brand that logs the reason alongside the timestamp can tell at the end of a week how many of its pauses were its own software rather than the platform’s judgement, and that ratio decides which team owns the problem.
A brand that consumes the webhook can therefore separate its own actions from the platform’s on the day rather than at the end of the month. A brand that does not consume it has no notification at all, and learns about the pause from a customer, a courier or a sales report.
What a DoorDash chain should hold ready before a store goes dark
A short list, kept current, because every item on it is slow to obtain under pressure. The banking record status for each store, the identifier of the active menu for each store, the account that holds Merchant Portal access per region, and the name of the person per branch who can physically reach the tablet outside office hours.
That list is the recovery time. Everything else on this page is instant once those four things are true, and stalled indefinitely when any one of them is not. What shows whether the list is current is not a status in the portal, it is the interval during which a store could not actually be ordered from, read against the hours that store published. Kitchain (kitchain.co) times those intervals on DoorDash storefronts from the customer side.
One closing distinction worth carrying into the incident log. A pause that ended in four minutes was noticed. A pause that ended exactly fourteen days later was never noticed at all, and no dashboard will ever draw attention to it, because by the time anybody looks the store is trading normally again.