You take nine trades. All nine work. You open your journal to admire the damage, and the profit factor field shows a dash.
Or a zero. Or 999. Or, if the developer was having a bad week, the page just stops rendering.
Nothing is wrong with your trading. The maths is doing exactly what it is supposed to do, and the software has no idea how to say so out loud. Most of us have hit this at some point and quietly assumed we broke something.
Profit factor is a genuinely useful number. It is also the metric I trust least on the samples where traders most want an answer — the first few weeks of a new strategy, when there is almost no data and a lot of hope. This post is about where it falls over, with real numbers.
First, the boring part: what profit factor actually is
Profit factor is one division.
Profit factor = gross profit ÷ gross loss
Gross profit is everything your winners made, added up. Gross loss is everything your losers cost, added up, as a positive number. You are not netting them against each other. You are asking: for every unit I lost, how many units did I make?
Say over 50 trades your winners brought in 8,000 and your losers cost 5,000. That's 8,000 ÷ 5,000 = 1.60. You made 1.60 for every 1.00 you gave back.
Above 1.00 means the sample made money, below 1.00 means it lost money, and that simplicity is the whole appeal.
Then reality shows up.
Failure one: nine winners and no losers
Go back to those nine trades. Say you risked one unit of account each time — traders usually call that 1R, one unit of risk, so a trade that makes twice what you risked is +2R.
Five trades closed at +1R, three at +2R, one at +3R. Gross profit is 14R. Gross loss is 0R, because you have not lost yet.
14 ÷ 0 = undefined
Not "very big." Undefined. An infinite profit factor is not a very large one, it's the arithmetic telling you there is nothing to divide by yet. There is no answer to that division, and no honest number to put in the box.
What software does with it varies, and every option is flawed. Some journals print ∞. It looks strange in a stat card, and plenty of traders read it as a bug. It is still the least-bad of the four, because it's the only one that doesn't invent a number. Some cap it at 999, which invents a value nobody computed. Some catch the error and fall back to 0.00, which is the worst one, because 0.00 is what a catastrophic loss run looks like. Some just throw an exception and the dashboard goes blank.
I know those last two in more detail than I'd like, because EdgeFlow shipped them. An account with no closed losers hit that division and the stat card broke, an edge case that never showed up in testing because our test data always had losers.
The actual bug was dumber than it sounds. The maths was fine. The server correctly computed infinity. But JSON.stringify(Infinity) returns null, so by the time the number crossed from the API to the browser it wasn't infinity any more, it was nothing at all. The dashboard then either rendered a confident 0.00 or fell over trying to call .toFixed on a null. The fix carries an explicit infinity flag across that boundary alongside the number, so the card shows ∞ instead of a fake zero. Uglier, and true.
I'll be straight about the state of that repair, since this whole post is an argument for not papering over things. The main dashboard and strategy stats go through the fixed path. There are older corners of our own analytics that still hand back a placeholder 999 when the loss side is empty, and we're working through them. If you ever see 999 in a profit factor field — ours or anyone's — read it as "no losers yet," not as a number.
Here's the thing worth taking away. Even with ∞ on the screen, what would you do with it? Nine winners in a row is a fun week, not evidence of anything. Expectancy on that same sample is 14R ÷ 9 trades = +1.56R per trade, which is at least a real number you can write down, and still not evidence of an edge with a sample that size.
Failure two: one trade owns the whole number
This one is quieter and does more damage.
Imagine 40 trades, one unit of risk on each. Fourteen winners, twenty-six losers, so a 35% win rate. Thirteen of those winners closed at +2R. One of them was a runner that closed at +12R.
Gross profit: 13 × 2R plus 12R = 38R Gross loss: 26 × 1R = 26R Profit factor: 38 ÷ 26 = 1.46
Respectable. Looks like a working strategy.
Now delete that one runner. Not because it wasn't real. It was. But to see how much of the number it was carrying.
Gross profit: 26R Gross loss: 26R Profit factor: 26 ÷ 26 = 1.00
One trade out of forty is the difference between "this works" and "this is exactly break-even before costs." And profit factor gives you no hint that this is happening. It is a ratio of two sums, and sums do not care whether they were built from many small pieces or one big one.
Expectancy has the same weakness, to be fair. It goes from +0.30R per trade to 0.00R on the same deletion. But expectancy usually gets reported next to median R and a distribution, so the problem tends to surface. Profit factor arrives with a rule of thumb attached ("above 1.5 is good"), and a rule of thumb reads like a verdict. That is what makes it dangerous. There is more on this specific trap in how a single outlier carries your expectancy.
Cheap habit that costs nothing: recompute profit factor with your single largest winner removed. If the answer changes character, you don't have a measured edge yet. You have one good trade and a lot of noise around it.
Failure three: it moves too much when the sample is small
Profit factor is a ratio, and ratios with small denominators jump around.
Take a run of 12 trades that landed at dead even: four winners at +2R for 8R of gross profit, eight losers for 8R of gross loss. Profit factor 1.00. Now watch four more trades go by.
| After trade | Result | Gross profit | Gross loss | Profit factor |
|---|---|---|---|---|
| 12 | — | 8R | 8R | 1.00 |
| 13 | +3R | 11R | 8R | 1.38 |
| 14 | −1R | 11R | 9R | 1.22 |
| 15 | −1R | 11R | 10R | 1.10 |
| 16 | +2R | 13R | 10R | 1.30 |
Four trades. The number lands on 1.38, 1.22, 1.10 and 1.30 on the way. If you check your dashboard on a Friday you might see a strategy that looks solidly profitable. Check it the following Tuesday and it looks marginal. Nothing about the strategy changed. You just added four data points.
Under roughly 30 trades this is what profit factor does. It is not measuring your edge, it is measuring which trades happened to land in your window. The reason is simple: with a small gross loss in the denominator, every new trade yanks the ratio around. Stability comes from volume, and there's no shortcut. This is the same effect that makes early win-rate readings and early "best setup" rankings so misleading, which I've written about in small sample traps in trading statistics.
Nobody can give you the exact trade count where it settles, either. A 70% win rate scalping strategy stabilises much faster than a 25% win rate swing strategy chasing 6R runners. Anyone quoting one universal number is guessing.
So what is a good profit factor?
The honest answer is that the question is slightly wrong, but here is how I read it.
Above 1.00 means the sample made money. That's it, that's the only thing profit factor tells you with certainty, and it only tells you about trades that already happened.
For the rest, context beats the number. A profit factor of 1.35 over 400 trades, where removing the best winner still leaves it above 1.20, is far more believable than 3.10 over 22 trades. The second one looks better and means less. Big profit factors on small samples are usually a sign that a couple of outsized winners have not yet met their matching drawdown.
One more thing quietly changes everything: whether the number was computed on gross or net results. Costs come out of gross profit and get added to gross loss, so they hit the ratio from both directions. A strategy at 1.30 before commissions and slippage can sit near 1.10 after them. If you don't know which your journal shows, check that before trusting any of it. It belongs to the same family of problems as duplicate fills and missing losers, covered in trading journal data integrity.
Profit factor vs expectancy
People treat these as rivals. They answer different questions.
Expectancy tells you what one average trade is worth. If your strategy runs at +0.20R per trade, then 100 trades is worth about 20R in expectation, and you can plan position sizing and drawdown tolerance around that. It's a per-trade number, in units you actually risk. If the term is new, start with what trading expectancy is.
Profit factor tells you the shape of the relationship between your wins and your losses on the sample you have. It's unitless and it scales with nothing, which makes it easy to compare across instruments but useless for sizing.
Expectancy is what I'd use to make a decision. Profit factor is what I'd use for a fast sanity check across several strategies. And both need the sample-size question answered first, or they're just decoration.
What I read next to it
Never in isolation. When I look at profit factor I want four other things on the same screen:
- Sample size. Not buried in a tooltip. Right next to the number.
- Largest winner as a share of gross profit. If one trade is 30% of your gross profit, you know what you're actually looking at.
- Median R alongside average R. When the average is far above the median, a few big trades are doing the work.
- The number recomputed without the biggest winner. Takes ten seconds and it has saved me from several strategies I was about to size up.
That list overlaps heavily with what belongs on any serious dashboard, which I went through in trading journal metrics.
This is roughly why EdgeFlow reports a likely range instead of one confident number, and ranks candidate edges by the cautious lower bound of that range. A 22-trade sample with one monster winner shouldn't outrank a 300-trade sample that grinds.
The rule I'd actually give a newer trader
Profit factor should never be the headline number on a small sample.
Put it in the second row of your dashboard. Read it after sample size and after distribution. Treat anything above about 2.5 on fewer than 50 trades as a question rather than a result, and go looking for the trade that produced it.
The metric isn't broken. It's a summary of trades that already happened, and it's being asked to behave like a forecast. That's on us, not on the division.
If you want to see what a strategy's numbers look like when the uncertainty is shown rather than hidden, that's the thinking behind EdgeFlow's analytics — there's a free interactive demo on the homepage if you'd rather poke at it than read about it.
Frequently asked questions
Why does my profit factor show infinity or a dash?
Because you have no losing trades in the sample, so the calculation divides by zero. That has no numerical answer. It is not an error in your trading, and it stops as soon as you take your first loss.
Is a profit factor of 2.0 good?
Over several hundred trades, yes, that's strong. Over 15 trades it means almost nothing, because a single large winner can produce it. Always read profit factor next to the sample size.
What is a realistic profit factor for a working strategy?
There's no published figure I can point you to, and anyone quoting one is quoting a feeling. What I can say is what the arithmetic implies: a strategy that clears its costs and survives a bad quarter usually isn't posting a spectacular ratio, and modest readings that hold up over hundreds of trades are worth more than high ones that don't. Very high readings usually come from short samples, from rare large winners that haven't met their bad stretch yet, or from data that quietly excludes losers.
Should I use profit factor or expectancy?
Expectancy for decisions about risk and sizing, since it is expressed per trade in R. Profit factor for a quick comparison between strategies. Neither one is meaningful before the sample is large enough.