Peloton’s engineering leaders have explained how the company keeps its biggest day of the year from falling over: they test on the live system that members are actually using.
Taq Karim, senior director of engineering, and Alex Niderberg, director of site reliability engineering, laid out the approach in an interview with TechTarget published this month. Peloton’s engineering team also published a detailed technical breakdown alongside AWS this week covering the same ground. Between the two, members get a look at what happens behind the scenes on days like Thanksgiving.
Peloton’s engineers describe Turkey Burn on Peloton as the single highest-traffic day and the largest surge of the year on the platform. What makes it hard is not just the volume but the shape of it. Ordinary web traffic ramps up gradually, while tens of thousands of members hit the platform at the exact same scheduled second when a class starts. Peloton’s team has a name for this: the “thundering herd.”
Here is what that looked like at Turkey Burn 2025:
- 7.27 billion total requests handled, peaking at 452,000 per second
- 34,600 members in the same ride at the same time
- 200 million+ requests to the leaderboard alone
- Zero major incidents
Members who have been around a few years know what happens when this goes wrong. That 2023 Turkey Burn saw roughly 20 minutes of server issues and downtime in the middle of the ride, during the Guinness world record attempt, and ended with an apology from Peloton’s CEO. Turkey Burn has run without major downtime in both 2024 and 2025.
The change between those years is the one the engineers described. Traditionally, a company like Peloton keeps a separate “performance environment,” essentially a copy of the real system used to run stress tests before anything ships to members. In 2024, Peloton got rid of theirs.
Their reasoning was that the copy was never really a copy. Peloton runs a large number of interconnected systems, and duplicating all of them precisely, including the data flowing through them, proved close to impossible. Small differences between the test version and the real one produced misleading results, which meant engineers were making decisions based on a picture that was slightly wrong. On top of that, maintaining the duplicate was expensive and consumed engineering time that could have gone toward member-facing features. Peloton says scrapping it contributed to a 40% reduction in what it costs to run Turkey Burn compared to previous years.
What replaced it is a mix of things. Engineers now use a high-fidelity staging environment as the last checkpoint before release, and then run load tests against the real platform, deliberately, at quieter times. Those tests push to around 2.5 times the expected capacity to find where things break, using an internally built tool called AutoLift that can scale the platform up to simulate event-level traffic. When something looks wrong, they stop the test, fix it, and resume. These run monthly through the year, ramping up to multiple times per week in the lead-up to Turkey Burn.
For a day like Turkey Burn, they use pre-scaling: building up capacity ahead of the surge rather than reacting to it. Peloton uses an internally built tool alongside an open source scaling system that can add server capacity in under two minutes if the available headroom starts running out. A second internal tool, called Gatekeeper, watches for database queries that are slowing down and shunts them aside before they drag on everything else. Its first live activation came during Turkey Burn 2024, and Peloton says it did its job without any members noticing.
Rather than designing systems around everything working, Peloton’s teams design around what happens when something breaks. Services are sorted into tiers, with the leaderboard, video streaming, and login treated as the ones that must never fail and given their own protected infrastructure. Engineers deliberately break lower-priority services in testing to confirm those failures cannot cascade into the critical ones, and during the busiest windows Peloton can switch off non-essential features to protect the parts that matter. There are also local fallbacks, such as caching workouts directly on the device, which is why your Bike or Tread can sometimes keep going even when something upstream is having a bad day.
The team also said they now treat cost as an engineering metric that sits alongside speed and reliability, rather than as a finance question handled elsewhere. Cost and performance data is reviewed weekly across the engineering organization, and a cost spike gets handled by the on-call engineer through the same process as a performance problem.
They were also candid about the limits. Niderberg said there are situations where testing in production is the wrong call, specifically when a failure would be catastrophic and impossible to undo. Karim listed prerequisites a company needs first, including real-time monitoring, automated kill switches that do not depend on one person calling another, and a culture where incidents are examined rather than blamed on someone.
Karim’s summary of the goal was: “The platform’s job is to be invisible.”
You can read the full interview in TechTarget here, and the more technical breakdown on the AWS blog here.
Did you get caught in any of Peloton’s past Turkey Burn outages?
Support the site! Enjoy the news & guides we provide? Help us keep bringing you the news. Pelo Buddy is completely free, but you can help support the site with a one-time or monthly donation that will go to our writers, editors, and more. Find out more details here.
Get Our Newsletter Want to be sure to never miss any Peloton news? Sign up for our newsletter and get all the latest Peloton updates & Peloton rumors sent directly to your inbox.
Leave a Reply