Published
Every config in my backtest database logs three ways a trade can end: it hits take-profit, it hits a stop, or it runs out the clock on a hard time-stop without doing either. I'd mostly ignored that third number, time_stop_rate, treating it as a side effect of whatever else was going on. Then I sorted all 12,331 configs by it. Win rate falls in almost a straight line as time-stop rate climbs. Profit factor barely moves at all. Two outcome metrics, one input number, two completely different answers.
Win rate drops nearly 30 points, top to bottom
| Time-stop rate | Configs | Avg win rate | Avg profit factor | Top-candidate flags |
|---|---|---|---|---|
| 0-10% | 2,785 | 76.3% | 2.03 | 47 |
| 10-20% | 2,078 | 71.6% | 1.23 | 3 |
| 20-30% | 1,892 | 67.0% | 1.13 | 0 |
| 30-40% | 2,013 | 64.9% | 1.09 | 0 |
| 40-50% | 1,710 | 61.2% | 1.04 | 0 |
| 50-60% | 894 | 57.9% | 1.02 | 0 |
| 60-70% | 515 | 54.2% | 0.98 | 0 |
| 70%+ | 444 | 48.0% | 1.11 | 0 |
That's 76.3% down to 48.0%, a 28.3-point drop in average win rate from the lowest time-stop bucket to the highest, across eight buckets that move in the same direction every single time. Formally it's a -0.41 Pearson correlation between time_stop_rate and wr across all 12,331 configs -- moderate, not perfect, but far from noise. Net profit correlates even harder, at -0.52. The top-candidate flag makes the same point in a cleaner form: 47 of my 50 flagged configs sit in the 0-10% bucket, the rest in 10-20%. Not one top candidate exists past a 20% time-stop rate. The exact range across all 50 flagged configs is 0.12% to 16.69%, averaging 4.13%. A config where more than one in six trades just times out, waiting for a move that never comes, has never once earned my top-candidate flag.
Profit factor doesn't care
Here's what I didn't expect going in. Run the same correlation against pf instead of wr and you get -0.04 -- statistically nothing. Look at the table again: profit factor drifts from 2.03 down to roughly 1.0 across most of the range, but then the 70%+ bucket, the worst win-rate bucket of all, actually ticks back up to 1.11. A config can time out on most of its trades and still hold a perfectly respectable profit factor, as long as the trades that do resolve on their own resolve well. Win rate measures how often you're right. Profit factor measures what you make when you are, against what you lose when you aren't. A high time-stop rate wrecks the first number by definition -- a timeout isn't a win -- but says almost nothing about the second, because it's silent on the size of the trades that didn't time out.
I checked whether this was just "any exit-reason rate predicts outcomes" by running the same bucket test on fi_rate, the rate at which a trade exits on a final invalidation stop. No clean pattern: win rate bounces between 64.0% and 70.0% across its five buckets with no consistent direction, and the top-candidate flags don't concentrate at either end the way they do for time-stop rate. Not every exit-reason column is a hidden predictor. This one specifically is, because a time-stop is really a measurement of how often the entry thesis simply failed to play out in either direction -- a different kind of signal than a stop-loss, which measures how often it played out against you.
What this changes about how I read a config
I used to treat time_stop_rate as a tiebreaker, something to glance at after win rate and profit factor already told the story. I'm promoting it. If I'm scanning a new batch of configs and want a single early filter before running the full GOOD_FOR_DEEP_TEST/is_top_candidate pipeline on all of them, sorting by time-stop rate and cutting anything above 20% would have discarded every single config that never produced a flag anyway -- without needing the rest of the pipeline to tell me so. What it won't do is tell me whether a low-time-stop config is actually profitable; for that I still need profit factor, because the two numbers are measuring different failure modes and one doesn't substitute for the other. If you're evaluating your own backtest exports, run win rate and profit factor through the profit factor calculator separately before trusting either one alone -- a strategy that looks clean on one axis can still be quietly broken on the other.
Method: 12,331 rows from our own backtest results table (the same pipeline behind backtest-reports.html), covering 5 strategy families across 176 live-tracked symbols. time_stop_rate, wr, pf and is_top_candidate are the pipeline's own logged fields. Correlations are Pearson's r computed across all 12,331 rows, not just the bucket averages shown above.