Why running apps lose runs, and how to avoid it

A missing run is rarely a mystery. It comes down to one detail you cannot see from outside the app: whether your track was written to storage while you ran, or held in memory and written once at the end.

Where a run lives while you are running

Your track exists in up to three places. Only one of them survives the app being shut down. The operating system holds positions it has collected but not yet handed over, the app holds a working copy in memory, and storage holds whatever the app has actually written down. The first place is not the app's to control. Apple's Core Location documentation states that a suspended app does not run and does not receive location updates, and that the system enqueues location updates and delivers them when the app runs again.

Some part of your run is always in transit.

The second place is the fragile one. How often the app moves it into the third decides whether you keep the run.

The save step is the single point of failure

Everything depends on one write. If an app writes the track only when you press save, the whole run is one object with one chance to be persisted, and a single failure at that moment takes all of it quietly, because the code that would report the problem is the code that just died. The alternative has a name. Wikipedia defines crash only software as a program that handles failures by simply restarting, without attempting any sophisticated recovery. You get there by keeping durable data current, so restarting becomes the recovery and not the start of one.

• Shut down while the summary or naming screen is open, before you tap save.
• A crash inside the save routine, so the write that mattered never completes and the run is still only in memory when the process ends.
• Storage busy, the write fails, and the failure is swallowed, not retried.
• A reinstall before you save.

What Strava says it cannot restore

Only one is recoverable. Strava draws a hard line between a run that was deleted and a run that was never saved.

If you record an activity on the Strava app, click finish, but don't save it, it is never sent to the Strava servers and, therefore, cannot be restored.

Strava Help Center, How to Restore a Deleted Activity, fetched 2 August 2026

Deletion is the reversible case. The same help centre article describes a Recently Deleted tab listing activities deleted within the last 30 days, reached through My Activities on the Strava website and not in the phone app, and that location matters, because a runner searching the app finds nothing and concludes the run is gone.

Any service can only restore what reached it.

Four failures that all look the same

Four events. One sentence: my run is gone. The wrong response destroys data that was still there.

Three of those rows are answered on the phone. In those three, a reinstall is what turns a recoverable run into a lost one. The deleted row is the exception: that copy sits on a server, so the phone is the wrong place to look and clearing the app costs you nothing.

Killed by the operating system, crashed, or out of battery

Apple treats shutdown as ordinary. Its documentation on reducing terminations in your app lists memory limit, memory pressure, a launch watchdog and background task timeout among the reasons the system stops a process, and says terminations are expected and cannot be fully eliminated. Background apps are terminated first when a foreground app needs memory. That is where a recording app spends the run.

Android is equally direct. Its processes and app lifecycle documentation states that an application process's lifetime is not directly controlled by the application itself, and warns that onDestroy is not guaranteed to be called when the system kills a process. The counterweight is the foreground service, which Android documentation says shows a status bar notification so the user knows a task is running. That notification is the visible sign the recorder is still running, worth a glance when you stop at a light. It is a strong claim on the system's attention, not immunity from it, which is why the two documents above still apply.

Doze is aimed at an idle device rather than one moving in your hand, but it is the plainest statement of what Android does to an app it believes has been left alone: suspends network access, ignores wake locks, defers standard alarms and does not let JobScheduler run. The phone sitting on a table after a run, with an upload still pending, is exactly that device.

A flat battery is harsher than either.

Crashes leave the operating system running, so writes already handed to it survive. A power cut gives nothing time to finish.

What writing during the run actually changes

It does not make recording lossless.

Unbounded loss becomes bounded loss. With a save at the end, what you can lose is the whole run. With a write on arrival, what you can lose is whatever the system had collected but not delivered, plus the interval while the app was not alive, which is a gap in the track and not a delay in it.

How Runflake records a run to disk

Runflake writes first and computes second. Positions reach the phone's database before the screen or the running totals see them.

1. Write before anything elseEvery GPS point is written to the phone's database the moment it arrives, before the app does anything else with it. There is no save timer and no save at the end step for the raw track.
2. One batch, one transactionEach arriving batch of GPS points is written in one all or nothing transaction, so a run can never end up with half a batch on disk.
3. A failed write is not a discarded writeIf a database write fails, the points are kept in memory and retried on the next batch instead of being thrown away.
4. Recovery replays the raw dataAfter a crash the app rebuilds the run by replaying the raw points, steps and events from the database. The stored summary is not trusted.
5. Finishing is not one fragile momentPressing Finish cannot crash the run away. The finish routine runs each step in isolation and records which ones failed, and the line that actually closes the run is retried on database contention.

On restart, an unfinished run is offered back. The card says "You have an unfinished run" with the line "Saved up to where it stopped", a Continue button, and a Hold to finish button needing a long press so a mis-tap cannot end the run. The offer stands for 30 minutes after the last heartbeat, after which the run is closed at the next launch and saved.

What a database can refuse to delete

A rule in application code holds only while every code path remembers it. A rule in the database holds against code nobody has written yet. In the app above, two SQLite triggers abort any attempt to delete a run row or its GPS points while that run has not yet been backed up to the server. Tests cover both directions: the delete throws while the run is unsynced, and succeeds once it is marked backed up or explicitly discarded.

The limits matter as much as the rule. Those two triggers guard deletion of the run row and its GPS points, and a delete rule can protect only what already reached disk. Erasing a recording is left to one deliberate path: you discard or delete it yourself, which marks it discarded and then removes the run and all seven of its side tables in a single transaction. The question is worth asking of any app you rely on: what stops a future bug from deleting a run that has not been uploaded?

What to check before you trust an app with a long run

Ten minutes on an easy run answers most of this. Do not save it for the morning of a race.

1. Force quit while recordingRecord, walk two minutes, force quit from the app switcher, reopen. A good result is an offer to continue the same run. A blank slate tells you the track was living in memory.
2. Record with no networkAirplane mode, a few minutes. The run should save locally and upload later. If saving needs a connection, every dead zone is a risk.
3. Look for an upload markerCheck whether history separates a run held only on the phone from one the server has confirmed. Without it, no moment is safe for a reinstall.
4. Read the help centre firstSearch the app's support site for the words unsaved and restore. What you find is the answer you get after a long run.
5. Check the background settingsOn Android, set the app to run unrestricted, not battery optimised. On both platforms, grant background location if you record with the screen off.

Without a watch the phone is your only recorder, which is the subject of running with only your phone. What an app says during a run is a separate question from what it writes down, covered in what running apps say out loud.

The first ten minutes after a run goes missing

Do nothing destructive first. A recoverable run usually becomes a lost one through a reinstall performed while looking for it.

1. Do not uninstall, reinstall or clear the app's storage. That removes the local database, the one place an unsynced run can still exist.
2. Open the recording screen before browsing history. Resume prompts are often shown only there, and only once per visit.
3. Check the phone's history list, not the website. A run that never uploaded is absent from the web and present on the phone.
4. If it was deleted, not lost, check the service's deleted items. Strava keeps activities deleted within the last 30 days in a Recently Deleted tab.
5. Export whatever exists before editing it. A partial file in your hands beats a complete one you are hoping for.
6. Note the start time, the end time and the app version. That is what support asks for first.

A longer walkthrough, including the case where the run sits on the phone but not on the server, is in how to recover a lost run. If a run is genuinely gone, the fix is not a better search. It is changing what records the next one.