Sold Out Before It Worked: A Post-Mortem of the BA × Amex 25th-Anniversary Avios Launch
At midday on 15 July 2026, British Airways and American Express opened bookings for one of the most hyped loyalty offers in recent memory: a one-off, Avios-only celebration flight from London to New York, laid on to mark 25 years of the BA/Amex partnership. Within seconds, the booking site fell over. By the time it was usable again, every seat was gone.
To grasp why this became a stampede, price it in cash. With a BA Companion Voucher, the headline redemption was two First Class seats from London to New York and back for 160,000 Avios with a companion voucher and not a penny in cash, no taxes, no fuel surcharges, with a BLADE helicopter transfer from JFK into Manhattan thrown in for good measure. The equivalent cash fare for two in BA First to New York routinely runs well into five figures; the helicopter hop alone normally costs around $200 a head. In plain terms, this was a £13,000-plus travel experience for points and nothing else, a redemption so far above the usual value of an Avios that people quite rationally bought Avios with real money just to get in on it, because even at purchase price the maths still worked. That is the size of the prize customers were queuing for 90 minutes of error pages. Hold that number in mind; it’s what makes everything that follows matter.
This is not another “the website crashed, how annoying” write-up. Plenty of those exist. What follows is a technical and operational post-mortem: what actually happened to the platform, why customers who did everything right were locked out, why the process wasn’t the fair race it was billed as, and, because that’s the useful part, what a well-run high-demand launch should have looked like.
I watched the endpoints throughout the outage and logged the behaviour as it happened, so much of the technical detail below is first-hand observation rather than inference from the outside.
The offer: engineered to be mobbed
To understand the failure, you have to understand the demand, and the demand was entirely predictable.
The deal was genuinely exceptional. A dedicated return flight – BA177 out of Heathrow on 15 October 2026, BA180 back from JFK on the 18th – priced in Avios only, with no cash and (unusually) no taxes or carrier charges to pay:
- World Traveller (economy): 25,000 Avios return
- World Traveller Plus (premium economy): 50,000 Avios return
- Club World (business): 100,000 Avios return
- First: 160,000 Avios return, including a one-way BLADE helicopter transfer from JFK into Manhattan
For context, a normal peak First Class redemption to New York runs far higher and comes with a substantial cash surcharge. And because BA’s Companion Voucher (“2-4-1”) could be applied, a solo traveller could book First Class for just 80,000 Avios return. This was, by some distance, the cheapest way anyone was ever going to sit in BA First to New York.
The mechanic itself all but guaranteed a stampede at a single instant:
- Eligible BA Amex Cardmembers registered their interest in advance (registration closed at 23:59 BST on 24 June 2026).
- Registrants were emailed a personalised booking link by American Express ahead of the launch.
- Bookings opened at exactly 12:00 noon BST on 15 July 2026, first-come, first-served.
So: a headline-grabbing, once-in-25-years deal, promoted for weeks across every UK frequent-flyer channel, funnelled into a hard 12:00:00 start with a fixed and obviously small number of seats on a single aircraft. Every ingredient of a traffic spike was known, in advance, to the day and the second.
Many customers went further than just showing up. Because seats had to be paid for entirely in Avios from your own account, a large number of people bought Avios with real money in the run-up specifically to have enough balance ready; exactly the behaviour BA’s “buy Avios” promotions are designed to encourage. That detail matters later.
The timeline: from launch to “sold out” without a working site in between
Here is the sequence as it actually unfolded.
12:00 – the doors open, and immediately jam. From the first moments, the booking URL returned HTTP 503 Service Temporarily Unavailable. Underneath the polite status code, requests were failing at the network level with upstream connection errors – the classic signature of origin servers that are either saturated or falling over faster than they can answer.
12:0x–12:4x – thrashing. Over the following period, the site cycled through a whole menagerie of failure states: 503 Service Unavailable, 502 Bad Gateway, 504 Gateway Timeout, occasional 404s, and outright dropped connections. That mixture is characteristic of a backend under load being repeatedly restarted or cycled in and out of a load balancer – servers briefly coming up, being flooded, and dying again before they can serve a page.
~12:46 – a managed error page appears. The raw errors were replaced by a deliberately designed holding page: a clean, branded card reading “Temporary Issue – We are having technical difficulties. Please come back soon while we get things working again.” The booking URL began 302-redirecting every visitor to a static /error.html. This is a step you take when you’ve decided to shed load: stop trying to serve the app, and bounce everyone to a lightweight page while you work.
~13:1x–13:3x – flickering, false hope, and caching traps. The real page began appearing intermittently – roughly one request in three would return the genuine ~318KB booking page, while the rest still bounced to the error card. Crucially, the real page and the error page were served with the same HTTP 200 status once you followed the redirect, so “the site responded” was not the same thing as “you can book.”
~13:29 onward – sold out. By the time the page could be loaded with any reliability, it displayed the message nobody wanted: “Seats are now sold out. We are sorry, there are no seats available for booking at the moment. Join the waiting list below.”
Read that timeline back, and the damning point is obvious: there was never a meaningful window in which the site both worked reliably and had seats. The seats sold out during the period when, for most customers, the site was an error page. As one reader put it on Head for Points, they “tried booking for 1 hr 27 mins, got to complete a couple of times and crashed and then bingo” – success, when it came at all, was a war of attrition against the platform rather than a fair click race.
Under the hood: five failures, explained
Let’s take the failure modes one at a time, because each one is a distinct, avoidable mistake.
1. No meaningful capacity for a spike everyone could see coming
A 503, at heart, means “I don’t have capacity to handle this request right now.” Getting a wall of them at 12:00:00 tells you the platform was provisioned for something close to normal traffic and simply fell over when the entirely foreseeable crowd arrived at once. This wasn’t a subtle load-testing miss; the demand curve here was a vertical line at a pre-announced timestamp. It should have been the easiest capacity planning exercise of the year.
2. The origin, not just the edge, was the bottleneck
The site’s edge/CDN and its main domain stayed healthy throughout – the root of avios.com responded normally the entire time. It was specifically the booking service behind it that collapsed. The 502/504 gateway errors are the tell: the front door (load balancer/CDN) was up and dutifully trying to hand off requests to origin servers that couldn’t respond in time. When your edge is fine, but your origin is timing out, you have a scaling problem in the application tier, not a network one.
3. A branded error page is not a queue
Deploying a polished “Temporary Issue” page shows somebody had anticipated the possibility of an overload – they’d designed the holding page in advance. But a holding page only tells people to go away and come back; it does nothing to manage who gets in when. It converts a chaotic error into a tidy-looking error. The customer experience is identical: refresh, hope, repeat. More on the thing they should have built instead below.
4. Cached redirects locked people out even after recovery
This one was quietly vicious. Once the site started 302-redirecting the booking URL to /error.html, many browsers cached that redirect. The practical effect: even after the underlying service partially recovered and began serving real pages again, affected users kept getting bounced straight to the error page by their own browser, which never re-asked the server. They were locked out by a stale redirect, not by a live problem.
You could confirm this directly: the same link that redirected endlessly in a normal browser session loaded the real page immediately in a fresh incognito window, or when a cache-busting parameter was appended to force a clean request. In other words, an unknown number of people spent the critical window staring at an error the server was no longer even sending. A correct Cache-Control: no-store on that redirect would have prevented the entire class of problem.
5. “Page loads” was mistaken for “booking works”
Because the static marketing/booking page was large and cacheable, it could be served intermittently from cache while the dynamic booking engine behind it was still saturated. So you’d get flickers of a fully-rendered page that then couldn’t actually complete a transaction. From the outside, monitoring for “did the page come back” would give false positives; the only signal that mattered – “can a real customer complete a booking end to end” – was the one nobody outside BA/Amex could see, and evidently the one that stayed broken longest.
The fairness problem: two doors, one of them unofficial
The technical failure was bad. The fairness failure is arguably worse, because it’s the part that turns “unlucky” into “unjust.”
Registered customers were sent a personalised booking link containing an individual account key. That link was the official, sanctioned route – and it was the one mired in redirects and error pages.
Meanwhile, in the comments of Head for Points’ launch-day article, readers began sharing an alternative link: the generic vouchers landing page (avios.com/en-GB/spend-avios/vouchers/amex), not the personalised link that Amex had emailed out. For at least some people, at least some of the time, this generic route behaved better and got them further into the process than the official personalised one.
Sit with the implication. The customers most likely to get a seat were not necessarily the fastest, most prepared, or most loyal. They were the ones who happened to be reading a particular forum at the right moment and knew to use an unofficial back door. Everyone who dutifully followed the official instructions – clicked the link Amex sent them, as told – was left fighting the worst-performing path. When the sanctioned route is the broken one and the workaround is folklore passed around in a comment thread, “first-come, first-served” has stopped meaning anything.
The human cost
It’s worth being blunt about who absorbed this. These weren’t speculators. They were loyal customers who:
- Registered weeks in advance, as required.
- Bought Avios with real money to top up their balances specifically for this flight.
- Showed up at exactly noon, links ready, as instructed.
…and were rewarded with an hour and a half of error pages followed by “sold out, join the waiting list.” Nobody’s Avios is literally destroyed – points topped up for this can be spent elsewhere – but people spent money in good faith, on the strength of a promoted promise of a fair process, and the process wasn’t fair. For an event whose entire purpose was to reward loyalty and celebrate a partnership, generating this much ill will is a remarkable own goal.
The response: a canned apology, and silence where an explanation should be
If the technical failure was an accident, the response to it was a choice – and it has been just as poor.
As of the following day, some 22 hours after booking opened, there was still no official statement on the Avios or British Airways website: no incident acknowledgement, no explanation of what went wrong, no formal apology, and nothing telling affected customers what – if anything – they can expect. Customers who contacted support were met with the usual pre-canned holding responses that don’t engage with the specific failure at all
.
The only public acknowledgement came via a two-part reply on X (Twitter). It thanked customers for their “patience,” attributed the collapse to “the very high volumes of booking requests,” said “we’re sorry for the inconvenience this caused,” and directed people to the waitlist. It was signed with a first name, in the house style of a routine service reply.
The problem isn’t the tone; it’s the substance. “Very high volumes” is not an explanation for this event – it’s a restatement of the thing they were supposed to plan for. The volume was not an unforeseeable act of nature; it was the entirely predictable consequence of promoting a limited, deeply discounted offer to a large registered audience and opening it at a single published minute. Blaming demand for a demand-driven event you designed is like blaming the rain for a picnic you deliberately scheduled outdoors in a storm. It reframes a capacity-planning failure as bad luck, and loyal customers can tell the difference.
Good incident response follows a well-worn shape: acknowledge quickly and specifically, explain honestly what happened, say what you are doing about it, and set out how affected people will be treated fairly. Nearly a day on, this incident had none of those. A prestige loyalty event that fell over in public deserved a prompt, named, substantive statement on the company’s own channels – not a single generic tweet and radio silence everywhere else. When the headline product is loyalty, the communications vacuum after a failure does its own, separate damage.
What “good” looks like: how to run a high-demand drop
The most useful thing about a failure this clean is that every mistake maps to a well-established fix. None of this is exotic; it’s standard practice for anyone who ships time-boxed, high-demand releases – such as ticketing, sneaker drops, exam results, and vaccine bookings. The playbook exists.
1. Put a real queue in front of it. The single biggest fix. A virtual waiting room (Queue-it, Cloudflare Waiting Room, AWS’s own patterns, and others) absorbs the 12:00:00 spike, admits users to the booking engine at a rate the backend can actually sustain, and – critically – assigns each visitor a fair, ordered place the moment they arrive. It turns a stampede into an orderly line. It also kills the fairness problem stone dead: there is one door, everyone is in the same queue, and no forum workaround can jump it.
2. Load-test to the known peak, then provision beyond it. The spike time and the eligible population were both known in advance. Model the worst case (assume nearly everyone arrives in the first minute, because they will), test against it, and autoscale the application tier – not just the edge – to match. A 502/504 storm means the origin was never scaled for the load the front door was happily accepting.
3. Degrade gracefully, and never cache your failures. If you must shed load, do it through the queue, not a redirect to a static error page. And if you ever redirect to an error page, send it with Cache-Control: no-store so recovering users aren’t trapped by their own browser cache. The cached-redirect trap here was pure unforced error.
4. Make the sanctioned path the best path. If a personalised, authenticated link is the official route, it must be the most robust one – not the most fragile. The fact that a generic public URL outperformed the emailed personalised link is a sign the personalisation/auth layer itself was part of the bottleneck. Test the official journey under load, because that’s the one your honest customers will use.
5. Communicate in real time. A status banner, a queue position, an honest “we’re at capacity, hold tight, your place is saved” – anything is better than silence punctuated by error pages. Uncertainty is what turns a delay into rage. People will forgive a wait they can see the end of; they won’t forgive being left refreshing a broken page with no information for 90 minutes.
6. Have a fairness story you can defend. First-come-first-served is a legitimate model – but only if everyone genuinely competes on equal footing. If the real constraint is that you have 100 seats and 100,000 hopefuls, consider whether a ballot among registered users would have been fairer and, ironically, far cheaper to operate: no spike, no meltdown, no back-door links, no war of attrition. Sometimes the most robust architecture is choosing not to run a millisecond race at all.
7. Own it afterwards, fast and on your own channels. When something this visible breaks, the recovery is half technical and half reputational. Put a named, specific statement on your own website within hours – what happened, what you’re doing, and how affected customers will be treated, rather than leaving a single generic tweet to do the work while support sends pre-canned replies. An honest post-mortem published by the company earns more goodwill back than any amount of “sorry for the inconvenience.” Silence reads as indifference.
The takeaway
The BA × Amex 25th-anniversary flight is a near-perfect case study because nothing about it was unforeseeable. A prestige, deeply discounted, strictly limited offer, promoted for weeks, released at a single published instant to a known audience – and the platform behind it was not ready for the one thing it was guaranteed to face. The result was a booking that sold out before it functioned, a “fair” race won partly on forum tip-offs, and a base of prepared, paying, loyal customers left with error screenshots and a waiting-list place.
The seats were always going to disappoint most applicants; there simply weren’t enough. That part is just scarcity. But there is a world of difference between “I didn’t get one because thousands of people wanted the same few seats” and “I didn’t get one because the website they told me to use didn’t work and the people who got in used a link off a forum.” The first is bad luck. The second is a failure of engineering and of fairness, and, unlike the scarcity, it was entirely within their power to prevent.
Twenty-five years is a long time to learn how to open a booking page. There’s always the 26th.
About the author: Jay Ralph works at Bridewell Consulting. Bridewell helps organisations build and secure digital services that hold up when it matters most – resilience, incident readiness, and the operational planning that stops a high-demand launch becoming a public post-mortem. If you’re preparing a launch, a ticket drop, or any event where everyone arrives at once, and you’d rather not read about it afterwards, get in touch.
Sources: Head for Points launch coverage; Head for Points offer preview; American Express newsroom announcement; LoyaltyLobby; FlyerTalk discussion thread. Technical behaviour of the booking endpoints was observed and logged directly during the outage on 15 July 2026.