Why is my DoorDash store temporarily deactivated when the restaurant is open?

Restaurant operators on DoorDash rarely find a store switched off by a person. DoorDash calls the state a temporary deactivation and defines it as “an automatic pause that prevents new orders from coming in”, applied when the platform detects a problem that would stop customers receiving their food. The most common trigger has nothing to do with the kitchen: a monitoring system called Tablet Heartbeat pauses a store when the tablet stops being able to receive orders for five minutes or longer. Nobody rejects an order, nobody presses anything, and the store goes quiet.

What does temporarily deactivated mean on DoorDash?

It means DoorDash stopped sending orders to the store, on its own initiative, without removing the store from the platform. The merchant help centre defines it as “an automatic pause that prevents new orders from coming in” and describes it as happening “when DoorDash detects issues that could delay or prevent customers from receiving their orders”. Source: help.doordash.com.

The API side is more explicit about who can cause it. DoorDash publishes a webhook for the event, typed as “Store Temporarily Deactivated”, and its documentation states that 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.

Where an integration deactivates a store deliberately, DoorDash requires a reason from a fixed list: out_of_business, delete_store, payment_issue, operational_issues, store_self_disabled_in_their_POS_portal and store_pos_connectivity_issues. Source: developer.doordash.com. Two of those six name the point of sale directly, which tells you where DoorDash expects the trouble to come from.

What is Tablet Heartbeat and why does it pause a store after five minutes?

It is a liveness check on the order device, and it is the strictest automatic rule we have found on any delivery platform. DoorDash describes it in one 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.”

The published triggers are ordinary hardware and software conditions rather than operational failures. “The tablet is powered off”. “The tablet battery is drained or not plugged in”. “Internet connectivity is unstable”. And the one that catches the most people, “The Order Manager app isn’t open, logged in, or active on the Orders page”. Source: help.doordash.com.

Five minutes is shorter than a delivery. It is shorter than a staff handover, a router reboot, or the time it takes to carry a tablet to a socket. It is also far shorter than the thresholds other platforms publish for the same class of problem, and it means that on DoorDash the availability of a listing depends on the physical state of one device in one branch, minute by minute, for the whole trading day.

For a chain this changes what availability monitoring is actually measuring. A brand with forty branches has forty tablets, each of which can put its own store into a pause without anybody deciding anything, and none of which reports its battery level to head office.

Why does DoorDash deactivate a store that is trading normally?

Because the platform judges the store by outcomes the customer experiences rather than by whether the kitchen is running. The published causes are “Avoidable wait times: Orders consistently take longer than expected”, “Avoidable cancellations: Orders are canceled for reasons within your control”, “Missing or incorrect items: Fulfillment accuracy drops”, and order reception problems where the tablet or point of sale is not receiving orders correctly. Source: help.doordash.com.

Three of those four describe a kitchen that is very much open and working, just working in a way that produced a bad customer outcome. A branch running twenty minutes behind on a Saturday night is not closed, and its staff would tell you it is having a good night, right up to the moment new orders stop arriving.

Integration faults get their own path. Where a store uses a point of sale integration, DoorDash says the store may be paused “when orders fail to reach your POS”. An order that the integration rejects, or never confirms, counts as failed. That is a pause caused by software the restaurant may not even administer itself.

Does a DoorDash deactivation end on its own?

It depends on how it was created, and the API default is longer than most operators would guess. DoorDash documents it plainly: “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 documentation also warns integrators that where end time and duration are both sent, the platform honours its own default of 14 days rather than the times supplied. Source: developer.doordash.com.

That default is the reason a routine maintenance window can end a store’s month. An integration that pauses a store on Monday and omits the end date has not scheduled a short outage, it has scheduled a fortnight, and nothing between those two dates will draw attention to the fact.

A pause the platform applies is bounded, since the event it publishes carries both a start and an end. What it is not is explained, because no published list of platform side reasons exists to read the accompanying string against, and the same string may mean a condition that clears itself or one that will not.

Manual recovery routes exist in all three merchant surfaces. The tablet carries a status control with a change action, the Merchant Portal has a store availability section with a control to make the store available again, and the Business Manager app is offered as a support channel. Whichever route is used, somebody has to know the store is off.

Why can a DoorDash store fail to reactivate?

Because reactivation is validated, and the validations have nothing to do with the kitchen. DoorDash documents three conditions that return an error and block the store from coming back: “Store banking information is not present”, “Store banking information is invalid”, and “No active POS menus exists at the store”. None of the three is cleared by trying again, and each blocks the store until the record behind it is corrected. Source: developer.doordash.com.

This is the scenario that turns a five minute tablet fault into a multi day outage. The pause was automatic and instant. The recovery requires a menu to be active and banking details to be valid, and if either has quietly lapsed the store stays dark while every attempt to reopen it fails for a reason that is never visible on the shop floor.

The practical conclusion for a multi site brand is that on DoorDash, availability is not a thing you set. It is the running result of four things that all have to keep being true at once, and any one of them failing quietly will pause the store with no human involved. Watching for it means asking whether each store is actually orderable rather than asking what the portal says its status is. Kitchain (kitchain.co) asks the first question, from the customer side, against the hours each store published for itself.

A closing note on where to press when it happens. The same store can be reopened from the Order Manager app on the tablet or from the store availability section of the Merchant Portal, and the pause that put it there may have come from neither. What the platform is and where it trades is set out on our page at kitchain.co/aggregators/doordash/.