Skip to main content

Amazon Flex's automatic "extra driving" payment adjustment — what we know so far (UK, 2026)

I got this email from Amazon Flex a few days after a block that ended up being much longer than the offer screen suggested:

Payment adjustment for more driving

Hi [name],

You're receiving a one-time payment adjustment for completing deliveries in your block on May 27, 2026 that involved significantly more driving than a typical route. You will see the payment adjustment of £5 in the Earnings section of the Amazon Flex app within 48 hours.

Thank you for delivering with Amazon Flex.

The Amazon Flex Team

Up until that email landed I didn't know this mechanism existed. After posting in the UK and US Flex subreddits I got real data from drivers on both sides of the Atlantic. This post is the corrected, multi-source picture of how the adjustment actually works.

What it is, in plain terms

Amazon's logistics system has an internal estimate of how much driving a block "should" take. When a delivered block comes in significantly above that estimate, the system automatically pays a top-up. You don't file anything. The money lands in the Earnings section within ~48 hours.

The rule is asymmetric in the driver's favour: routes shorter than the estimate never get a deduction, routes significantly longer get a kicker. So an over-driving block that initially feels like a loss can end up close to net-neutral.

The amount range — what drivers actually report

Based on the Reddit threads (linked below), here's the documented picture:

  • UK £5 is the baseline. Most drivers who've gotten one report £5 — the default the system pays when the threshold is tripped.
  • Higher amounts on bigger overruns. One driver reported £12.50; another £25 for a ~200-mile route; the highest documented so far is £39.99.
  • US: $5 default. US drivers confirm the same mechanism, default $5, same auto-trigger pattern.
  • Long blocks without the email exist. One UK driver reported 103 miles with no adjustment; another got nothing on a low-paid high-mileage block. So it's not pure mileage.

The trigger isn't just total mileage

The actually-useful insight from the threads is that the heuristic isn't "how many miles did you drive" but more likely the ratio of block time to delivered mileage. Drivers report getting adjustments on relatively short 2-hour blocks that overran on miles, and getting nothing on long 4-hour blocks that hit higher absolute miles. Amazon's not publishing the threshold and never will, but treating it as a ratio rather than an absolute fits the reported pattern better.

You cannot request one manually

This is the bit I had wrong in the first version of this post and want to correct cleanly. The adjustment is automatic only. There is no support channel that will issue one on request. As one experienced UK driver put it bluntly on the Reddit thread: "you cannot email requesting a mileage adjustment. It is automatic, and automatic only." If Amazon's system didn't trip the threshold, no human at support can override that.

What this means practically: don't waste time on a support ticket about a block you think should have triggered one. If it did, it'll land within 48 hours; if it didn't, no escalation route exists.

Don't confuse it with the "earnings guarantee"

A separate but related mechanism: if a block runs over the scheduled time (rather than the expected mileage), Amazon's "earnings guarantee" tops up so the driver still gets the block's base pay despite the extra clock time. Drivers in the thread flagged this as a different email and a different system. So:

  • Payment adjustment for more driving = mileage-overrun top-up, automatic, this post.
  • Earnings guarantee = block-time-overrun top-up, also automatic, different email subject.

If you see one and not the other, the system flagged one trigger but not the other — they're independent.

Where the data came from

These threads are open for more reports if you want to add yours, especially if you've gotten an unusually high or low one or any pattern that points to what the threshold actually is:

The bigger point about block evaluation

This adjustment is one of the reasons "is a block worth taking" maths is harder than the offer screen suggests. Some over-driving blocks recoup via this mechanism, but it's outside your control whether any specific block triggers it. The block-evaluation framework still holds: assume you won't get a top-up, build your floor from that, and treat any actual adjustment as upside.

Related reading

Disclaimer

Grabber is not affiliated with, endorsed by, or built by Amazon. Amazon Flex is a trademark of Amazon.com, Inc. The data points in this post come from a single UK Flex driver's email plus driver reports on Reddit; Amazon does not publish the threshold or per-mile rate for this mechanism, so everything here is a best-effort reading of how it appears to work in practice and may change.

Comments

Popular posts from this blog

How to tell if an Amazon Flex block is actually worth accepting — the real maths every UK driver should run

Amazon Flex shows you a headline rate on every block offer. £45 for 3 hours. £18.50/hr. £22.00/hr. Those numbers look fine until you put them through the actual maths a driver does after the fact, and most of them turn out to be a different number than the one on the offer screen. This post is the maths you should be running before you accept, not after. It's the same conversation that happens in every UK driver thread on Reddit — most drivers eventually find their way to a version of this calculation, but it usually takes a few burnt Saturdays first. The headline number is misleading on purpose The £/hr Amazon shows you is the block window divided by the pay. That's the time the route itself takes, from your first drop scan to the last. Everything outside that window — and there's a lot of it — is unpaid. The real time you spend on a block looks more like this: Drive to the depot. Unpaid. Depends on which station you got the offer from. Depot wait time. ...

Amazon Flex bot detection in 2026 — why on-device block grabbers differ from cloud commission bots

Amazon's 2025 enforcement push made one thing clear: not all third-party block grabbers carry the same risk. The same Reddit threads that report "my account got flagged after I started using bot X" almost never describe the same architecture as the apps that don't show up in deactivation stories. The difference isn't whether automation is allowed — it isn't, per Amazon's terms. The difference is which detection signals each kind of tool leaves behind. This post is a technical breakdown of those signals: what cloud commission bots look like to Amazon's backend, what on-device accessibility-based grabbers look like, and what Grabber specifically does to keep its cadence pattern closer to a human driver's. None of this is a claim of undetectability — that doesn't exist. It's an explanation of why two block grabbers from the same Reddit thread can have very different deactivation profiles. What Amazon's 2025 enforcement actually targe...

What actually gets you deactivated from Amazon Flex in 2026 — and what doesn't

Every Amazon Flex driver thread eventually circles back to the same anxiety: am I about to lose this. Deactivation is the only thing about Flex that's genuinely punitive — every other problem (rate variance, station drama, route quality) is annoying but solvable. Deactivation is final. This post is what's actually known about Flex deactivation in 2026 — from Amazon's own enforcement posts, from driver reports across r/AmazonFlexUK and r/AmazonFlexDrivers, and from the patterns that appear consistently in deactivation stories. It isn't insider knowledge. It's the public picture, organised so you can stop worrying about myths and focus on the things that actually matter. What Amazon's terms actually say The Independent Contractor Agreement — the contract you ticked when you signed up — lists clear grounds for termination. Paraphrased, the main ones are: Failure to deliver in accordance with Amazon's operational standards. Theft, contraband, or v...