Some of your branches are offline on DoorDash and the rest are fine
Restaurant chains on DoorDash are not running one listing with many addresses, they are running many listings judged separately. What DoorDash applies is “an automatic pause that prevents new orders from coming in”, and every condition that produces one is evaluated at a single address. Each store has its own tablet, its own point of sale link, its own banking record and its own customer outcomes, and every one of those four can pause a single location while the rest of the brand keeps trading. That is why a DoorDash estate splits rather than fails together.
What does DoorDash evaluate per store rather than per brand?
Everything it uses to decide whether orders should keep flowing. Its merchant help centre gives four headline causes, and each one is phrased as an observed outcome at a location rather than as a policy: “Avoidable wait times”, “Avoidable cancellations”, “Missing or incorrect items”, and orders failing to reach the tablet or the point of sale correctly. Source: help.doordash.com.
Not one of the four is a brand attribute. They are records of what customers of a particular address experienced, so a kitchen that is falling behind on a Saturday builds up its own score while the branch across town builds up a different one. Improving an estate average changes none of this, because the platform never looks at an average.
The device layer behaves the same way. Tablet Heartbeat is described as a system that “automatically pauses your store if your DoorDash Tablet can’t receive orders for five minutes or longer”, and the triggers DoorDash names are ordinary hardware and software conditions rather than service failures. Forty branches therefore means forty batteries, forty connections and forty screens, and each of them can pause its own store with nobody deciding anything.
Why does one DoorDash store keep pausing while its neighbour never does?
Because five minutes is short enough that ordinary branch habits decide the outcome. A store where the tablet lives on a charger in view of the pass will almost never trip the rule. A store where it is carried into the kitchen, or shares a socket with the card terminal, will trip it repeatedly. Neither branch is doing anything anybody would call wrong, and the difference between them is furniture rather than performance.
That is the honest reason estates diverge on this platform, and it is worth saying plainly to whoever is reviewing branch performance. A store with a recurring pause pattern is usually reporting a physical arrangement, not a management failure, and the fix lives in the branch layout rather than in a training session.
The second reason is integration coverage. Where a store uses a point of sale integration, DoorDash states that the store may be paused when orders fail to reach the point of sale. A chain that connected twelve of its eighteen stores during one rollout now has twelve stores exposed to that path and six that are not, and the six will look better in any report without being better run.
What does store_self_disabled_in_their_POS_portal tell a franchise operator?
That DoorDash expects a store to be switched off by software the brand may not administer at all. Its fixed list of deactivation reasons for integrations runs to six values, and this is the one that names somebody else’s console: store_self_disabled_in_their_POS_portal, sitting beside store_pos_connectivity_issues, payment_issue, operational_issues, out_of_business and delete_store. Source: developer.doordash.com.
For a franchised brand that value explains most single location mysteries. A franchisee changes something in their own till system, the till system reports it onward as a deactivation, and the brand is left with a dark listing and no corresponding entry anywhere in its own tools.
Capturing the reason is therefore the highest value thing an integrated group can do here, since it is the only place the authorship of a closure is preserved. The webhook exists for exactly that, typed as “Store Temporarily Deactivated”, and DoorDash notes that causes range from a merchant pausing itself in the portal through to automatic deactivation on quality grounds. Source: developer.doordash.com. The full vocabulary for platform initiated cases is not published, so some reason strings arrive without a documented meaning behind them.
A DoorDash store can be blocked from reopening by a record that has nothing to do with the kitchen.
This is what turns a five minute fault at one location into a multi day absence while the rest of the estate trades. Three documented conditions make a reactivation request fail, and two of them are financial: banking information for that store being absent, banking information for that store being invalid, and the store holding no active point of sale menu. DoorDash notes that these keep failing until the underlying record is corrected. Source: developer.doordash.com.
Banking details are held per store. A group that opened a new company for its newest three locations, or that changed banks for one region, or that has a franchisee whose account details lapsed, now has stores whose recovery path is blocked by paperwork. The pause was instant and automatic. The recovery requires a finance record to be valid, and nobody standing in the branch can see which of the two they are dealing with.
The same is true of menus. A store with no active point of sale menu will not come back, so a failed menu publication at one location converts every subsequent pause at that location into an outage of unknown length.
Why do two DoorDash stores recover at different speeds after the same fault?
Because the fallback duration depends on how the deactivation was written, and integrations across one estate are rarely written the same way. Where a deactivation request carries no end date, DoorDash applies a default of two weeks and reactivates the store automatically once that has passed. It also warns integrators that sending both an end time and a duration does not override that default.
So a store deactivated by a well built integration carries an end time and comes back on schedule. A store deactivated by an integration that omitted the field is off for a fortnight unless a person intervenes. Both events look identical in the branch and identical to a customer, and they differ by roughly two weeks of trading.
Manual recovery exists in three surfaces, the tablet, the Merchant Portal and the merchant mobile app, but all three require somebody to know the store is off. A brand with stores connected through different integrators, or through one integrator configured at different times, should expect exactly this spread.
How should a multi store brand compare DoorDash stores against each other?
By separating the four populations before comparing anything. Stores with a tablet against stores without. Stores behind a point of sale integration against stores taking orders directly. Stores whose banking and menu records are current against stores where either has lapsed. Stores whose deactivations carry an end time against stores whose deactivations do not.
Once an estate is grouped that way, the question of why some branches are offline usually answers itself, because the dark ones cluster. What that grouping cannot do is tell you when each store stopped being orderable, since a deactivation is visible in the portal only while it lasts and a pause that lifted overnight leaves nothing behind. The record that survives is one taken from outside, store by store, against the hours each store published, which is what Kitchain (kitchain.co) collects across a DoorDash estate rather than reading a single merchant dashboard.
One closing caution about reporting. On DoorDash availability is not a setting a brand holds, it is an outcome produced continuously by a device, an integration, a menu and a banking record at each address, so an estate wide availability target is only meaningful when it is measured per store and then read as a distribution.