Who built this
The Debrief is built and run by Ruurd-Jan Zwarts. It is an independent project, not a company with a team behind it, and it is free to use with no account.
If you want to ask something about a report, or disagree with one, the address is info@thedebrief.cc and the reply comes from the person who wrote the code.
What the engine measures
Your FIT file is parsed in full, then the bike and run are read together — that pairing is the whole idea, because most triathlon run problems are written into the bike that preceded them. The analysis is distance-aware: a 70.3 and a full distance are judged against different numbers, which is the mistake most hand-analysis makes.
The bike, over 70.3
- Target intensity factor 0.75–0.80. At or above 0.82 we call it an overbike; at or below 0.72, under-ridden.
- Variability index at or under 1.05 is a smooth ride; past 1.08 the surging carries a cost of its own.
- Power-to-heart-rate drift under 5% is normal; over 10% is decoupling worth acting on.
- Second-half fade under 3% is unremarkable; over 5% is significant.
The bike, over full distance
- Target intensity factor 0.68–0.73, overbike from 0.75 — below where the 70.3 target band starts.
- Drift under 10% is normal across five or six hours; over 16% is the real signal.
- Fade under 5% is tolerable; over 10% is significant.
The run
- A first-half to second-half split within 2% (70.3) or 3% (full) is excellent execution; within 5% is acceptable.
- An opening kilometre more than 5% faster than your eventual average is a hot start, and it changes which story the rest of the run tells.
Where it gets argued with
The tool was posted on the Slowtwitch forum, and the most useful response was a critical one. An athlete ran three of his own races through it and reported that without an FTP supplied, it kept landing on “you overbiked” — and he quoted the report’s own words back at it: “a 10-watt error in your FTP input flips the verdict between absorbed and overbiked.”
That is a fair hit, and it is the reason the section below exists. A verdict that swings on ten watts of an input the athlete half-guessed is a verdict resting on the wrong thing. The engine leads with demonstrated power because of criticism like that, not in spite of it. The thread is public if you want to read the exchange rather than take my word for how it went.
Why it compares against what you have held, not your FTP
Intensity factor is only as good as the FTP underneath it. A large share of age-group athletes are working from a number that is stale, was estimated rather than tested, or came from a ramp test that flatters them. Every percentage computed from a wrong FTP is wrong by the same margin, and that is the single most common way a self-diagnosis goes astray.
So the primary comparison is against power you have demonstrably sustained — a level the engine finds by looking for an effort that repeats across more than one long window in your own file, rather than taking a stored FTP on trust. Where the file cannot support that, the report says which anchor it used and how much weight that deserves.
What it will not tell you
The engine checks its own inputs before it speaks. It needs around 80% power coverage, 80% heart-rate coverage and 90% GPS coverage across a leg before it treats that channel as evidence. Below those lines the finding is qualified or withheld.
If the file cannot support a verdict, the report says so. Calling an overbike you did not commit is worse than leaving the question open, and a tool that always produces a confident answer is telling you about its own design rather than about your race.
What happens to your file
You can use the tool without an account. What is collected, why, and how long it is kept is set out in the privacy policy, which also names the data controller — the same person named at the top of this page.
See it on a real race
The clearest answer to “what does this actually produce” is a full sample debrief, generated by the same code path your own upload would take, on a 9:12:22 full-distance file.