Setup
-
Dawarich server 1.8.1, self-hosted (Docker)
-
Dawarich iOS 2.4.104
-
Accuracy: Balanced · Distance filter: 10 m · Time filter: 10 s · Track breaking: 30 min
-
Tracking was active before, during and after the incident
What happened
On 6 August 2026 the app recorded 9 points between 17:01:28 and 17:07:35
(accuracy 13–34 m), then nothing at all until 18:25:39 — a gap of 78 minutes.
Why this is not simply “no movement”
Between 18:16 and 18:25 I walked roughly 1 km outdoors, open sky, from a cafe
to Central station. Not a single point was recorded for that walk. The first
point after the gap arrives at 18:25:39, once I had already reached the station.
For reference, on a normal outdoor day this exact configuration produces around
880 points per hour, so the tracker is clearly capable of far more than what it
delivered here.
The decisive evidence: uploads stopped entirely
The app uploads on a fixed ~5-minute timer, clearly visible server-side as
regular POST /api/v1/points requests (20:45:54, 20:50:55, 20:55:55, 21:00:56,
21:05:56 … with about one second of drift per interval).
During the 78-minute gap, not one upload request reached the server —
roughly 15 consecutive uploads missing.
This distinguishes two failure modes:
-
If only location delivery had stalled, the upload timer would have kept
firing with empty or minimal batches. Those requests would still appear in
the server log. -
The complete absence of any request indicates the app process itself was no
longer running — terminated rather than suspended or starved of location
updates.
The resumption at 18:25:39, roughly on arrival at a new location, is consistent
with iOS relaunching a terminated app on a significant location change.
What I did not do
I did not stop tracking, did not force-quit the app, did not swipe it away from
the app switcher, and changed no settings during this window. Battery was at a
comfortable level throughout. I did not touch the phone at all between 17:00 and roughly 17:30. The only notable context is that I was indoors in a dense city centre, where GPS fixes
are poor. That may be an indirect factor — struggling for a fix costs power and
memory — but it cannot explain the missing uploads: the upload timer is
independent of location quality, and the app buffers points locally for later
transmission. Had this been a signal or connectivity problem, the resumed
session would have carried a backlog. It carried none; those points were never
recorded.
Impact
The failure is completely silent. Nothing in the app indicates that recording
was interrupted, so the loss is only discoverable afterwards by noticing a hole
in the timeline. Server-side visit detection has no points to work with for that
window, so the stay is lost entirely — no setting on either side can recover it.
Expected behaviour
Background tracking survives memory pressure, or — if termination is
unavoidable on iOS — the app detects the gap on relaunch and surfaces it, so the
user knows data is missing rather than silently assuming the timeline is
complete.
Happy to provide
Full point dump for the window, server-side request log for the same period, or
to test a build. I am continuing to log and will report back if this recurs.