Why Most Period Apps Get Irregular Cycles Wrong

If your cycles vary and your app keeps telling you your period is late when it isn't — or says nothing while you wait two extra weeks — the problem usually isn't that the app is careless. It's that the arithmetic underneath almost every period tracker assumes something about your body that isn't true.

This is an explainer about why cycle prediction is hard, written by the people who build one of these apps. We'll be specific about what our own code does, including where it still falls short. There is no accuracy percentage in this article, because we don't have one worth quoting and neither, in our view, does anyone else.

The averaging problem

Nearly every tracker predicts your next period the same way: take your recent cycle lengths, average them, add that to your last period start.

For cycles that cluster tightly — 28, 29, 27, 28 — this works well. The average is 28, every individual cycle is close to it, and a prediction built on it will be within a day or two.

Now take cycles of 45 and 28 days. The mean is 36.5. There is no cycle in that history anywhere near 36.5 days — the average describes a cycle you have never had. A prediction from it will be roughly a week late for the short cycle and more than a week early for the long one. It is wrong in both directions, every single time, and it will look confidently wrong: a specific date, stated plainly.

It's worth being fair about why so many apps do it anyway. Averaging is defensible: it is simple, it is easy to explain, it behaves predictably, and for the majority of users whose cycles are reasonably regular it produces good answers. An app serving tens of millions of people optimises for the middle of that distribution. If your cycles vary, you are not being ignored out of malice — you are outside the range the model was tuned for.

The missed-log problem, which looks identical

There is a second failure that compounds the first, and it is genuinely difficult rather than merely overlooked.

Suppose you have 28-day cycles and you forget to log one period. The app doesn't see a missed entry — it sees one 56-day cycle. That single number now sits in your history looking exactly like a real long cycle, and it drags every subsequent prediction later.

The awkward part is that a genuinely long cycle and a missed log produce the same data. Nothing distinguishes them from the outside. An app that discards long intervals to protect its predictions will throw away real cycles from people who actually have them — which is the worst possible group to discard data from, because they are the people most in need of an accurate picture.

What we do instead, specifically

Three things, none of them clever, all of them in the open. This is what the code in our cycle module actually does:

And a limitation we'd rather state than have you discover: with fewer than three intervals to work from, the median sits between your real length and a doubled one, and a missed log genuinely cannot be told apart from a real change. In that situation we keep both rather than guess, which means early predictions are the least reliable ones. There is no way around this that doesn't involve inventing information.

The same problem shows up in symptom patterns

Prediction is the visible failure. There is a quieter one in how apps report which phase your symptoms cluster in, and it took us a while to notice it in our own work.

Under the conventional 28-day mapping, the four phases are wildly different lengths: menstrual is about 5 days, follicular about 8, ovulatory is a single day, and luteal is about 14. If you count how many times a symptom was logged in each phase and name the winner, luteal wins roughly half the time by construction — not because anything happens in your luteal phase, but because luteal is the biggest target. A symptom occurring at random will be reported as a luteal pattern. And the ovulatory phase, being one day out of twenty-eight, can essentially never win no matter how strong the real signal is.

The fix is to divide rather than count: what fraction of your logged luteal days had this symptom, against the fraction of your logged follicular days. That puts a one-day phase and a fourteen-day phase on the same footing. It is not a sophisticated correction — it is the correction — but ranking by raw count is an easy mistake to make and an invisible one to live with, because the output looks perfectly reasonable either way.

Saying nothing is a feature

The last piece is the one we'd argue for most strongly, and it's the thing that separates a tracker you can trust from one that merely feels responsive.

When there isn't enough data to support a claim, the honest options are to hedge it or to withhold it. Hedging is more satisfying to build — the screen stays full, the app looks like it is working. But “you might get headaches in your luteal phase” from four logged days is not a softer version of a finding. It is a non-finding wearing the costume of one, and readers reasonably remember the claim and forget the hedge.

So our pattern cards have sample floors and a minimum margin, and when a claim doesn't clear them nothing is shown at all. A phase needs enough logged days before its rate counts. A leading phase has to beat the runner-up by a real margin rather than a rounding difference. A comparative claim needs at least two phases with enough data — one phase “winning” against nothing is not a comparison. If none of that is satisfied, the card is absent.

The same principle governs what does appear. Once three completed cycles are logged, we'll show your actual cycle lengths and how much they vary, because variation is a statement about the differences between cycles and two cycles give you exactly one difference. Once you've logged the week before your period across three cycles, symptoms that reliably arrive first can be named with a number of days — and only if most of those cycles agree with the number, because “typically two days before” drawn from onsets of one, five, two and six days would describe none of them.

Where this still falls short

Two honest limits, because a post about other apps overstating things would be a poor place to start overstating our own.

An interval longer than about four months is treated as a gap in logging rather than a cycle, and left out of the prediction sample. That is the right call when the cause really is a lapse — someone stopped tracking and came back — and the wrong one in the rarer case where a cycle genuinely runs that long. Separately, an interval that looks like two cycles recorded as one is dropped too, measured against the median of your own cycles rather than a fixed number; that is right when a period log was missed and wrong when your cycles have genuinely doubled in length. Neither exclusion substitutes a default any more — if nothing in your history qualifies, you get no predicted date rather than a made-up one — but they are still judgement calls made on your behalf, and we would rather write them down here than let you find them.

And more fundamentally: none of this makes an irregular cycle predictable. A tracker can stop making an unreliable cycle look reliable, it can show you the range you actually live in instead of a single confident date, and it can keep quiet when it doesn't know. It cannot tell you what your body will do next month. Any app claiming otherwise about irregular cycles is describing a marketing position, not a capability.

What to check in whatever app you use

You don't need to take our word for any of this — it is testable from the outside, in a few minutes:

If your cycles are irregular enough that this article felt personal, that is worth a conversation with a clinician rather than an app — irregular cycles have causes, some of them treatable, and a tracker's job is to give you a clear record to bring to that conversation, not to substitute for it. What a good log can do is turn “my cycles are all over the place” into six dated intervals and a symptom history, which is a far more useful thing to arrive with.