May Update on the 2026 Boston Marathon Cutoff Time Prediction

My last major update on the Boston Marathon cutoff time projection came at the end of March. The projection was 5:20, and things had been moderating slightly for several weeks.

But as I said then, April could prove to be an impactful month, with results from both Boston and London, along with many other races. And April did not disappoint.

I also made an update to the Boston Marathon Cutoff Time Tracker to make a calculation based on each runner’s best time – instead of using each and every unique finish.

I published a thorough update in Runner’s Life on Medium. If you’re not a Medium subscriber, you can request a link to get behind the paywall here. These updates also go out for free to newsletter subscribers, and if you use the form to subscribe you’ll get these feature articles direct to your inbox every Sunday.

Keep reading below for a brief synopsis of what has – or hasn’t – changed.

Race Results from April

The first order of business is – what happened at races throughout the month of April? Between Boston, London, and the rest of the races there were a lot of finishers.

First, Boston saw a surge in qualifiers compared to last year.

The weather last year was hot, depressing the qualifier count. This year also saw a higher than usual number of finishers, since the field size bumped up by about 2,000. The field was also primed to be fast, given the 6:51 cutoff time from last year.

As a result, there were ~12,800 qualifiers this year compared to ~9,800 last year. That’s inclusive of the new qualifying times.

You can read more about the Boston results here – but this inevitably pushed the cutoff time much higher.

The following week, London saw a net decrease in qualifiers.

Although the race grew in size, it’s already obscenely large. The field grew by about 5%, and that’s not enough to offset the impact of the new qualifying times. It was also a hot day, and fewer finishers than expected met their qualifying times.

The net result is that the number of qualifiers at London dropped by about 2,700 compared to last year. This brought the cutoff time back down to earth – kind of. You can read more about the London results here.

Finally, there was a full slate of other races, totaling about 60,000 finishers. Many of these races saw large increases in the number of finishers compared to last year, and some saw an increase in the number of qualifiers. It followed the pattern that we’ve seen playout all year.

When you look across the entire month, there were about 500 fewer qualifiers than last year – a 2% drop. That’s much smaller than the year to date difference prior to April (8%), which means that the net result of this month is to push the cutoff time higher and lock in the likelihood of a high cutoff time.

Methodology for De-duplicating Results

Until now, the cutoff time projection has been based on the raw number of finishers and qualifiers. But now that we’re deep into the spring marathon season, and more runners are likely to have run multiple marathons, I’ve updated the methodology behind the tracker.

To group the results by runner, I started by estimating a potential range of birthdates for each result. Then, I used fuzzy matching to identify runners with the same (or similar) names, who were of the same gender, from the same country, and who had overlapping potential birthdates. For runners from the United States, I also checked to see if their state differed as a way to weed out false positives.

While this methodology will miss some actual duplicates and identify a handful of false positives, it’s a good approximation. Most importantly, the same methodology was applied to both qualifying periods, and the biggest question we need to answer is the delta between last year’s qualifying period and this year’s qualifying period.

This took quite a bit of work to get set up. But now that I’ve created the workflow, it’ll be easy to incorporate new results and continue to process them in the same way moving forward.

In the tracker, you’ll now see an option titled, “Use Fastest Time.” If that is set to True, the dashboard will make calculations based off of each runner’s fastest time. If that is set to False, the dashboard will make calculations based on all results.

Did De-duplicating Results Change Things?

In short, no.

As I’ve warned previously, the key question is not how many of this year’s runners have multiple qualifying times. And de-duplicating the results will not automatically reduce the number of qualifiers and the cutoff time projection.

The key question is how that compares to last year.

Since the methodology is applied consistently to both qualifying periods, de-duplicating the results will reduce the number of qualifiers in both the 2025 qualifying period and the 2026 qualifying period.

If the number of runners with multiple results is about the same, nothing will change. If there were more runners with multiple results this year, that would lead to the cutoff projection going down. And if there were more runners with multiple results last year, that would lead to the cutoff projection going up.

As it turns out, the number of runners with multiple marathons and multiple qualifying times is about the same when you compare last year to this year.

When I de-duplicated the results, last year’s total number of finishers was reduced by 46,504 (9.3%). This year’s number of finishers was reduced by 50,483 (9.0%). About the same.

And whether you compare total finishers or unique finishers, the number has increased 12-13% compared to last year.

If you zero in on qualifying times, the same pattern holds true.

The number of qualifiers in last year’s qualifying period was reduced by 7,865 (11.6%), while the number of qualifiers in this year’s qualifying period was reduced by 7,239 (11.3%). And by either comparison, the number of qualifiers this year is only slightly lower than the number of qualifiers last year.

It’s quite likely that my matching methodology missed a small number of potential duplicates. But there’s no reason to think that sub-sample would be any different from the duplicates that were actually identified – and in the positively identified group, there is a clear and consistent pattern from last year to this year.

So Where Do Things Stand?

No matter how you slice it, these two things remain true:

  1. The number of finishers is up significantly compared to last year.
  2. The number of qualifiers is down only slightly compared to last year.

The inevitable result of that is that the number of applicants (36,393 last year) will be reduced only slightly (likely 33,000 to 35,000). Assuming the number of accepted applicants remains the same (24,000), this requires the elimination of about 10,000 applicants.

And that means a cutoff time in excess of 5:00.

To put things simply:

  • A cutoff time under 4:00 is likely out of the question
  • A cutoff time of 4:00 to 5:00 is possible but very unlikely
  • A cutoff time of 5:00 to 7:00 is likely, with 5:30 to 6:30 being the most likely outcome
  • A cutoff time of 7:00 to 8:00 is possible but very unlikely
  • A cutoff time above 8:00 is likely out of the question

From here on out, very little is likely to change due to new results. About 90% of the qualifying period (counted by finishers) is locked in, with only about 10% remaining. A large race like Grandma’s could influence things slightly, but it couldn’t shift the entire window.

If you are interested in doing your own analysis, I plan to share the full dataset that I’ve been working with on Kaggle by the end of the month. I needed to clean things up first – and the de-duplication process helped me do that.

I also plan on doing a final deep dive over the summer, taking a closer look at what factors could predict how likely a given runner is to actually apply to Boston. That could narrow things down a little more.

As always, follow me on Threads for the most timely updates – and sign up for my weekly newsletter to get this kind of analysis in your inbox.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.