A run recap shows one row per kilometre, with a figure on the right. That figure said one thing: how long this kilometre took.

Which seems enough, right up until you actually look at your own list. A musher sent us his: kilometres at 3:45, and in the middle of them a 6:14, a 6:37, a 7:03. Three kilometres where the team apparently fell apart — except it didn't. He had stopped inside them. A tangle in the lines, a dog to move, someone met on the trail. The table said none of that anywhere.

And his question fit in one sentence: I'd like to display speed in km/h rather than min/km — or switch between the two, and be able to choose with or without stops.

Two toggles, above the table

min/km ↔ km/h. The same second, read the other way round. Some people think in pace, others in speed; there is no reason for us to decide that for you. Your choice is kept on your phone: you make it once.

with stops ↔ moving only. This is the one that answers the screenshot. On "moving only", kilometre 2's 6:14 becomes what it really was — 3:50, plus two and a half minutes standing still.

One detail that isn't a detail: the highlighted kilometre moves. On the outing we used as a test, the last kilometre was hiding a 2:10 behind two minutes of stopping. In elapsed time it went unnoticed; in moving time it is the fastest of the whole run, and it lights up. The highlight follows the clock you picked — otherwise it would point at a row its own figures contradict.

What it shows to nobody

None of this leaves your phone. It isn't outing data, it's a reading preference: it doesn't sync, it appears on no page of the website, and no member of your kennel or your club can tell which unit you read your splits in. Change phones and you'll pick once more.

And no recorded figure moves. The distance, the moving time, the average speed of the outing are exactly what they were. The toggle changes what the table displays, never what the logbook holds.

What it does not do — and that isn't "not yet"

On outings recorded before 7 August 2026, the "moving only" toggle simply does not appear. This isn't an oversight: to remove a stop you have to know when it happened, and until that date the app only kept a total — not moments in time. The raw GPS points you could re-derive them from are wiped from the device after two weeks, deliberately (they are bulky, and they are yours). An outing imported from a file doesn't have them either.

So no, those outings will not get the toggle later. We would rather assert nothing than manufacture a plausible stop.

An outing where you never stopped doesn't show it either: there is nothing to remove, and a button whose only possible outcome is the state you are already in isn't a button.

So the two cases look the same on screen, and that is deliberate. An early version put a line on old outings saying "stops were not recorded for this outing". True — but it would have shown up across almost an entire season of history, explaining on every single open an absence nobody was looking for. This article replaces it: it is said here, once.

The website doesn't change. A trace page already shows time and speed in two columns side by side: half the request was already met there, and stacking a toggle onto a table that already shows both would help nobody.

The decision taken against the obvious

There was a simpler way to do "without stops": look at the trace, decide that below a certain speed you weren't moving, and subtract. That method has one massive advantage — it works on 100% of outings, history and imports included. No missing toggle, and this whole section would not have needed writing.

We didn't take it, and here is why.

The app has long known what a stop is: it's the rule that pauses the clock while you ride, and it's the rule that produces the "moving time" shown at the top of your recap. A second calculation, with its own threshold, would not have agreed with it. You would have had, on the same screen, a moving time at the top and splits that don't add up to it. Two contradictory figures, with neither of them wrong.

We have paid that price elsewhere, more than once: two ways of computing the same thing always drift apart eventually, and on the day it happens nobody knows which one to believe. An honest absence on old outings seemed cheaper to us than a permanent contradiction on all of them.

The stops you remove are therefore exactly the ones the app observed during the outing. The same ones that paused the clock. Not one second more.

One limitation, while we're here

If your phone genuinely lost GPS for a long stretch — not a stop, a loss of reception — the trace's time axis is compressed at that point, and a stop located after that gap may be placed slightly off. That was already true of the stops shown on the website's map; this release neither worsens nor fixes it. The remedy would mean storing an absolute timestamp for every point, which is an entirely different piece of work.