What happens to a run when the GPS drops out

A gap in your track is not a gap in your run.

You kept running. The phone stopped being able to say where you were. What an app does in the seconds between the last usable fix and the next one decides whether the number at the end is a measurement or a guess wearing a measurement's clothes.

None of it shows while you run. It shows up afterwards, as a total that is slightly too generous, a pace spike at one point on the graph, or a split called out in the wrong place.

Three things an app can do with a gap

Only three exist.

Accuracy is not the difference between them. It is what kind of number you end up holding.

The first two are indistinguishable on a summary screen. Both hand you one number with no marker on it. The third changes the type of the number, not its size. It stops being a claim about how far you ran and becomes a claim about how far you ran at least.

An app can mix the first and the third, filling short gaps and dropping long ones, and where it draws that line is the interesting part. So the useful question is not whether your app interpolates. It is what test it applies before it accepts a line it did not measure.

Why interpolating across a gap flatters the total

A straight line across a gap is a guess with both a length and a direction. The two points it connects are themselves uncertain, and that second part is the one people forget.

No fix is a point. Apple documents horizontalAccuracy as the radius of uncertainty for the location, measured in meters, with the reported latitude and longitude at the centre of that circle, and Android's Location class returns the estimated horizontal accuracy radius in meters at the 68th percentile confidence level, so the true position is inside that circle roughly two times in three.

So the endpoints of a gap are two circles, not two dots. Stand at a light while the reported position wanders inside its own uncertainty, and the line between the first fix and the next is not a distance you ran but the difference between two guesses, which an app that accepts any straight line will accept as distance.

The opposite case exists too. You really did run through the gap, but not in a straight line, so the line under reads. Nothing in the data separates the two. GPS.gov lists satellite signal blockage from buildings, bridges and trees among the factors that degrade positioning, and notes that the government commits only to broadcasting a signal with a daily global average user range error of 2.0 m or less, with 95% probability. GPS.gov then says plainly that this is not user accuracy. Blocked sky is where runners stop at crossings and where they turn corners, so both failure cases cluster in the same places.

Interpolation never announces itself.

No summary screen has a field for how many metres were filled in. That is part of why the same route on two phones produces two different totals, which is a longer story of its own.

Recording a lower bound instead of a guess

Make the app prove the line. That is the alternative, and three tests do most of the work. You can apply the same reasoning by eye to your own tracks.

1. Is this still one segmentPast some ceiling, the two fixes are not the ends of a gap. They are two pieces of a run stitched together, and no line between them means anything.
2. Is the implied speed possibleDivide the straight line distance by the elapsed time. If the answer is faster than a runner can move, the line describes something other than running and should contribute zero.
3. Is the line longer than the doubtCompare the line against the combined uncertainty radius of both endpoints. If the line is shorter, standing still explains the data as well as moving does, so it is not evidence of distance.

Runflake applies tests of this shape. When a line fails one of them the segment contributes nothing, and the gap is recorded as excluded, not filled. When GPS gaps caused distance to be dropped from a run, the run records how much time was excluded, so the distance can be presented as a lower bound rather than a measurement. Those seconds are kept as a number attached to the run instead of being absorbed into the total, which is the whole difference between a figure you can qualify later and one you cannot.

An under count you can see is worth more than an over count you cannot.

It also fixes a comparison problem. A Tuesday loop with forty seconds excluded is not the same kind of measurement as a Thursday loop with none, and a marker tells you which to distrust. Runs that record their own defects are easier to argue with later, which matters when a run goes missing or arrives incomplete.

What the coach should say, and why silence is a choice

Only the current announcement is worth making. After a gap, if a signal drop hides two kilometre markers and you cross the third as the fix returns, hearing all three in sequence tells you nothing. The first two describe places you are no longer standing.

Runflake works this way: if GPS drops out and you cross several kilometre or mile markers at once, the coach announces only the last one instead of reading a backlog. The counters still advance, quietly. The same engine throws away any cue that has waited more than twelve seconds, on the principle that a late announcement is a wrong announcement. The test to apply to whatever you run with is simple: a split read out four hundred metres after the marker is not late information, it is wrong information.

Silence during a gap is a decision, not an absence.

An app that says nothing while the signal is out has decided the gap is not worth interrupting you for, and that a screen you choose to look at can carry the fact instead. That is defensible. Silence you cannot tell apart from a crash is not, which is why the state belongs somewhere visible even when it is unspoken. More on those choices in what running apps say out loud.

Every suppression needs an expiry. While you are off a course the kilometre readout is muted so route guidance is not buried, but that muting expires after two minutes so a runner who abandons the course still gets splits again. Any rule that silences one thing while another is urgent needs a clock on it, because the urgent thing may never resolve and the silenced thing was useful.

Following a route while the signal is unusable

When an app cannot place you, the honest state is not off route. It is not checking. Those are different sentences and only one of them is true.

Runflake stops judging the course when GPS drops mid-route, and says so: "No usable signal, so the course is not being checked. Your run keeps recording." It does not declare you off it. There is a second version of the same pause for the case where fixes are still arriving but are too vague to compare against a line, and it names low accuracy, not lost signal, as the reason it stopped.

That second case exists because the off route corridor is not a fixed width: 2.5 times the phone's own reported accuracy, floored at 45 m and capped at 80 m. A corridor derived from a bad accuracy reading would be wide enough to contain the next street over, and a test that cannot fail is not a test.

The subtler problem is telling one missing sample apart from a lost signal. Confirming that a runner has left a route takes continuous seconds of evidence, so an app that discards its evidence whenever a single sample is rejected will almost never confirm anything where samples are being rejected, which is exactly where you need it. A gap of up to 5 seconds between usable fixes does not reset the off-route evidence, and turn cues are not pushed forward while course judging is suspended, so a signal gap cannot make the app skip past a corner. The pointer to the next corner is held through the pause instead of being pushed forward, so it has not run past the corner by the time checking resumes, and if the corner is close by then you get one instruction at the corner instead of the advance one.

What none of this does is put you back on the route. There is no recalculated path and no arrow home. Checking resumes when checking is possible, and the map is what gets you back. If you run where signal loss is routine, tunnels and urban canyons are worth understanding before you trust any route feature in them.

Reading your own track afterwards

One run is enough. Work out which policy your app used from the last one you did somewhere with poor sky, and look for these five things.

1. Find the impossible straight line. A segment running perfectly straight for hundreds of metres across ground that is not straight is a filled gap, not a record of your running.
2. Compare moving time with elapsed time. Where the two diverge, something decided you were not moving, or could not tell.
3. Look for a gap or excluded time field at all. If the app has nowhere to put that number, it has no policy you can audit.
4. Check the pace trace at the edges of the gap. A filled segment divides invented distance by measured time, so a spike going in and another coming out is a signature worth learning.
5. Run the same loop twice. Totals that agree everywhere except the tunnel section are telling you about the gap policy, not your fitness.

Then use the answer. A run that reports excluded time is a lower bound, so log it as one and do not chase a personal best on it. A suspiciously clean straight line through a dead zone is the opposite problem, and the sensible move is to stop weighing that route against routes recorded in the open. Neither run is ruined. They are different kinds of evidence, so know which one you hold.