Last week, Swiggy Instamart notified me: “Your delivery agent has arrived at your location.”
I went to the door. Nobody there.
I checked the tracker. The agent was still at the store.
This wasn’t a one-time glitch. I’ve seen it multiple times on Swiggy and on Flipkart Quick Commerce. Same false trigger, same confused user standing at the door.
After thinking about it, the engineering reason is pretty obvious.
The “Arrived at Location” milestone
Every delivery app has a milestone system. Ordered → Packed → Picked Up → Arrived → Delivered.
“Arrived at location” is supposed to mean: the agent is at your doorstep. Go downstairs. The handoff is seconds away.
It’s a trust signal. Break it, and you train users to ignore the tracker entirely.
Bug #1: The Dark Store Proximity Problem
Swiggy and Blinkit operate dark stores, small fulfilment warehouses spread across neighbourhoods for fast delivery.
One of Swiggy’s dark stores in my area happens to fall within what I suspect is their “arrived at location” radius check.
The trigger is almost certainly a simple calculation:
if (distance(agent_location, delivery_address) <= ARRIVED_RADIUS) {
triggerArrivedEvent()
}The problem: the agent is at the store, which is close to my address, and the app marks them as “arrived at my location” the moment they pick up the order.
They haven’t moved toward my building yet. They just happen to be nearby.
Bug #2: The Route Geometry Problem
The second scenario is subtler.
Road networks don’t follow straight lines. Sometimes the optimal route from the store to your address briefly passes through or grazes the “arrived” radius circle before curving away toward the actual destination.
The agent touches the invisible boundary. The app fires the event. The agent then continues riding for another 5 minutes.
You’re standing at the door. They’re still minutes away.
Both bugs share the same root cause: a naive point-in-circle check with no awareness of delivery intent.
What the fix looks like
“Arrived at location” should not be a pure proximity trigger. It should be a composite signal:
- Agent is within the radius AND moving toward the address (not away)
- Agent velocity is decreasing (slowing down, not passing through)
- Order status is past “picked up” for at least N minutes
- The agent has not been within the radius before (eliminates the store proximity false positive)
None of this is hard. It’s just a matter of treating the milestone as an intent signal rather than a coordinate check.
Why this matters
“Arrived at location” is a user commitment. Every false trigger erodes trust in the tracker.
After enough false arrivals, users stop going to the door proactively. They wait for a call. Which defeats the entire purpose of real-time tracking.
The Zepto search bug I wrote about earlier was a query normalisation failure. This is a geometry failure. Different systems, same pattern: a simple implementation that works 90% of the time and silently breaks for the remaining 10% in ways that hurt real users.
I can’t always reproduce this on demand. It depends on which store gets assigned and what route the agent takes. But I’ve seen it enough times on both Swiggy and Flipkart to know it’s not a one-off.
If you’ve experienced this, you already know the frustration. You’re standing at the door, phone in hand, and the agent calls you, still minutes away, asking for directions.
The tracker lied. And it didn’t have to.
A few weeks ago, I wrote about how Zepto’s LLM search silently fails new users – a different system, the same pattern. A simple implementation that works for most users and quietly breaks for the rest, with no feedback loop to fix it.
This is the same story. Quick commerce is moving fast. The core delivery promise “10 minutes, real-time tracking” deserves engineering that’s actually as sharp as the marketing.