Why Your DoorDash Delivery Time Keeps Moving After You Order
DoorDash and Uber Eats don't show a fixed delivery time -- they show a live prediction that updates itself repeatedly, and the model behind it is doing real engineering work.
Twenty-eight minutes. Then 34. Then 26 again, before the food has even left the kitchen. Nothing about the order changed -- the number on the screen just isn't a promise. It's a live prediction, recalculated every time new information arrives.
That distinction is the whole story. A delivery-time estimate on DoorDash or Uber Eats is the running output of a machine-learning model, not a countdown clock, and the two behave very differently. A countdown ticks down at a fixed rate. A prediction jumps whenever its inputs do -- a kitchen falling behind, a driver picking up a second order along the way, traffic thickening on the one road between the restaurant and a customer's building.
What the model is actually watching
DoorDash's own engineers describe the plumbing on the company's engineering blog. The problem, as they frame it: a genuine routing engine, the kind that calculates a real driving path road by road, takes more than 100 milliseconds to return an answer -- too slow for an app that has to estimate fees and match drivers to orders continuously, for millions of deliveries at once. Their fix, called Geo-Grid-Cache, divides every market DoorDash serves into hexagonal cells using a geospatial indexing system called H3, then pre-computes travel times between roughly 6 billion pairs of those cells offline, using Databricks' Spark platform to do the math ahead of time at three levels of geographic resolution. When an order comes in, the app doesn't calculate a fresh route -- it looks up an estimate that was already sitting in cache.
That cached-lookup trick is why the first number on screen appears almost instantly. It's also, indirectly, why it moves: a cached estimate reflects average road conditions for that pair of cells, not the specific truck blocking a specific street at that specific minute, so the app layers live signals -- where drivers actually are, how backed up a kitchen currently is -- on top of the cached baseline as the order proceeds.
Uber Eats solved a related problem with an even more granular approach. Rather than trust GPS alone, which the company's engineers found too noisy on its own to tell whether a driver is parked, walking, or waiting at a counter, Uber layered in motion-sensor data from drivers' phones to infer the exact stage of a pickup. The pain point was real enough that Uber quoted a delivery partner directly in its own writeup: "The pickup is sometimes not ready at all... sometimes even 20 minutes." That waiting time, multiplied across a fleet, is exactly what these models are built to shrink.
Why "batching" moves the number around
Part of what makes an estimate swing is a business decision hiding inside the math: order batching. Both platforms let one driver carry orders from more than one pickup in a single trip when doing so raises overall efficiency without stretching any single delivery too far past its own estimate. If a driver already en route gets assigned a new order because it's two minutes off their existing path, that order's ETA might briefly get worse -- even as, system-wide, more deliveries arrive on time.
Why does the time go up after I've already ordered?
Usually one of three things: the restaurant is running behind its typical prep time for that hour, the originally assigned driver dropped the delivery and a replacement is being routed in, or traffic along the route changed since the first estimate generated. None of these require anything to have gone wrong -- they're the normal inputs a live model responds to.
Is the estimate just made up to keep me from canceling?
No public evidence supports that read, and the engineering literature argues the opposite: both companies have a direct financial incentive to get the number right, since a badly missed estimate creates support tickets, refund requests, and customer churn. The more defensible criticism runs the other way -- these are probabilistic forecasts tuned for the fleet-wide average, not a guarantee for any single order.
Does tipping more make the estimate more accurate?
Tipping can influence how quickly a driver accepts an order, which indirectly affects the assignment-time stage of an estimate. It has no bearing on how long a kitchen takes to cook or on road traffic -- the two stages behind most mid-order swings.
None of this is unique to food. Open a maps app mid-drive and the arrival time creeps the same way, adjusting to a reported slowdown a mile ahead before the car has even reached it. The number was never fixed to begin with; it was always a forecast wearing a countdown clock's face, and once that's clear, the jumping stops feeling like a glitch and starts looking like exactly what it is -- a system doing its job in public.
