Does DoorDash tell you when your restaurant goes offline?
Restaurant operators on DoorDash are covered by one of the few purpose built events in this category. DoorDash publishes a webhook typed “Store Temporarily Deactivated”, and it carries start_time and end_time fields, so the message says both that the store went dark and how long the platform expects it to stay that way. What DoorDash does not do is put that message anywhere a person will find it. The event is delivered to an integration endpoint, and the branch learns about the pause from the absence of orders.
Which DoorDash event fires when a store is switched off, and where does it land?
An event named after the state itself, delivered over the Marketplace webhook channel to whatever URL an integrating developer has registered. DoorDash describes the range of things that trigger it in one sentence, 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.
That sentence is doing a lot of work. It puts a deliberate pause by a manager and an enforcement action by the platform into the same event type, which is convenient for a developer and confusing for anyone downstream. Both arrive identically shaped. Only the contents separate them.
The delivery address is the part that decides whether the notification exists at all in practice. A brand with a point of sale integration or a middleware layer has somewhere for the event to land. A brand running DoorDash from the Merchant Portal and the tablet has no registered endpoint, which means the platform generated an event about their store that had nowhere to go.
Does the DoorDash webhook say who deactivated the store and why?
Partly, and the asymmetry is worth understanding before an incident rather than during one. A deactivation raised by an integration is not allowed to be silent about its cause. DoorDash makes the caller pick from six named reasons, listed with their exact values here, two of which point at the point of sale.
Notice which direction that vocabulary faces. It exists so that software acting on the restaurant’s behalf can explain itself to the platform. Nothing in it obliges the platform to explain itself to the restaurant in the same terms, and the reasons DoorDash uses for its own pauses are not published as a comparable list.
Coming the other way there is no published equivalent. DoorDash’s help centre explains the operational causes of a platform deactivation in prose, listing avoidable wait times, avoidable cancellations, missing or incorrect items, and problems receiving orders. Source: help.doordash.com. Those are categories a person can read, not codes a system can switch on. An operator receiving an event about a deactivation the platform initiated has a machine readable notice of a decision described only in human readable terms.
How long can a DoorDash store be dark before anyone in the branch is told?
Long enough to matter, because the fastest trigger on this platform involves no human decision at any point. DoorDash states the rule plainly: “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 all conditions of a device rather than events in a kitchen. “The tablet is powered off”. “The tablet battery is drained or not plugged in”. “Internet connectivity is unstable”. “The Order Manager app isn’t open, logged in, or active on the Orders page”. Source: help.doordash.com.
Follow the sequence through. A tablet stops answering, so nobody in the branch is looking at it. Five minutes later the store is paused. The pause raises an event addressed to a server, and the one screen that would have shown a banner about it is the screen that was already unreachable. The alert path and the failure path run through the same device, and the device is the thing that broke.
For a chain that structure repeats per branch. Forty branches means forty independent five minute clocks, each attached to a battery and a router that head office cannot see.
What does DoorDash report to the merchant rather than to a machine?
The state, in three places, all of which have to be visited. The Order Manager app on the tablet carries the store status and the control to change it. The Merchant Portal holds a store availability section where a paused store can be made available again. The Business Manager app exists as a further route. Each of those answers one question for whoever opens it, namely whether the store is paused at this moment.
None of them answers the question that matters during service, which is whether the store changed state in the last ten minutes and whether anybody knows. A status screen consulted at nine in the evening reports the situation at nine in the evening. It carries no obligation to have told you at ten past eight.
The asymmetry between the two sides of DoorDash is unusually clean. Integrated systems receive a timestamped event describing a transition. Humans receive a current value on a page they have to open. The information is the same and the delivery model is opposite, and most chains are living on the second one.
Why does a failed DoorDash reactivation stay invisible on the shop floor?
Because the failure is returned to whoever made the call, and that is usually software. DoorDash documents three conditions that block a store from coming back and return an error: “Store banking information is not present”, “Store banking information is invalid”, and “No active POS menus exists at the store”. Source: developer.doordash.com.
None of those three is visible from a kitchen. A lapsed banking record and a menu that stopped being active are administrative facts, and the person pressing the reactivation control in the branch sees an attempt that did not work rather than a reason it did not.
The other quiet interval is the default duration. DoorDash writes it down: “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.” Fourteen days is a backstop, not a recovery. A store deactivated without an end time during a maintenance window is a store whose automatic remedy arrives roughly a fortnight after it was needed.
What should a multi site brand do with a DoorDash notification it may never see?
Treat the event as a bonus rather than as the control. If an integration exists, route the deactivation webhook to a channel a person actually reads during trading hours, and record start_time against the branch, because that timestamp is the only free piece of forensic evidence DoorDash hands over. If no integration exists, accept that the platform’s notification layer is not addressed to you and build the answer from outside.
The outside answer is the same question a customer asks, checked continuously: can this store be ordered from right now, and does that match the hours the store published for today. That comparison catches the tablet that went quiet, the deactivation nobody was told about, and the reactivation that silently failed, without depending on any of the three merchant surfaces above. Kitchain (kitchain.co) puts a timestamp on each of those intervals across DoorDash storefronts, which is what turns a manager’s impression that one branch keeps dropping out into a pattern somebody can argue from.
Across the storefronts we watch, a typical listing loses roughly a full trading day a month while about a third lose nothing at all, and the share of lost hours differs between platforms by multiples rather than by percentages. On a platform where the commonest trigger is a device going quiet for five minutes, the branches at the wrong end of that spread usually have a hardware problem rather than an operating one.