What happens if the field app is force-quit: catching tracking gaps

What happens if the field app is force-quit is a question every operations and HR team running a field workforce eventually runs into. A phone dies, someone swipes the app away from the recent-apps list, or a location permission gets revoked — and from that moment the system stops receiving position data. The stakes are real: if the gap goes unnoticed, a timesheet can end up both inflated and incomplete, and a manager only finds out hours later, with no idea when or why it happened.

Why the app stops: the user or the operating system

A device can stop sending location for two distinct reasons. The first is a deliberate user action: force-quitting the app, revoking the location permission from settings, or powering the phone off. The second is the operating system's own behavior — battery-saving modes, background refresh restrictions, or long periods of inactivity can lead iOS in particular to terminate an app on its own. Either way, the result looks the same from the server's side: a device that was reporting location suddenly goes quiet.

The distinction worth holding onto is that tracking continues uninterrupted as long as the app stays open or in the background. The problem starts only when the user force-quits it or the system revokes the permission. At that point, the only real fix is catching the gap as quickly as possible and getting it in front of the right people.

How the five-minute check works

The way to solve this is to expect a location ping from every device at regular intervals and flag the moment that expectation isn't met. In HR-Tech's field tracking module, this check runs every five minutes: if a device hasn't reported a position within that window, the system automatically flags it as a tracking outage. Because the evaluation happens on the server rather than the device itself, the outage record still gets a correct timestamp even if the device is broken or powered off.

In practice, this means that if an employee turns off their phone mid-shift, the manager finds out within minutes, not while reading an end-of-day report. The employee sees the same thing on their own home screen — tracking has stopped. That visibility cuts both ways: it also reduces the "am I being tracked without knowing" anxiety, since the system shows its state openly instead of hiding it.

Who gets notified, and when

A detected tracking outage doesn't go to just one side. Both the employee and that site's manager are notified instantly. On the employee's side, the notification is usually a simple reminder to reopen the app; on the manager's side, it names exactly who stopped reporting, at which site, and since when. If a site has more than one site manager, the alert reaches all of them, so the gap doesn't slip through because one person happened to be unavailable.

This mirrors the logic already built into violation alerts for staff who step outside a site during a shift: one says "we don't know where they are," the other says "we should be tracking them and can't." Both reach the manager within minutes rather than waiting for an end-of-day roundup.

How an outage gets reflected in the timesheet

The important question is whether the outage period should count against the employee or in their favor. The right approach is neither: an outage is never automatically marked as worked time, nor automatically marked as unworked. Instead, the flagged gap becomes a review task for that site's manager — was the employee actually on site during that period, or had they already left? The manager can resolve it by reaching out to the employee directly or by checking the location data immediately before and after the gap.

This echoes the approach covered in tracking off-site duties for field teams: a system doesn't always need to produce a hard yes or no — what matters is that ambiguity never slides silently into a report. A tracking outage stays a flagged field until a manager resolves it; it never quietly resolves itself into ordinary working hours.

Not to be confused with offline mode

A tracking outage is a different situation from offline operation, and that distinction matters. A device working at a site without coverage queues its locations locally and sends them in batches once connectivity returns — that's a planned delay, not an outage. You can read more on this in offline mode for field employee apps. The real outage is when a device stops sending location entirely and isn't even adding to a local queue — exactly what happens when the app is force-quit or the permission is withdrawn.

Being able to tell these two situations apart lets a system separate a genuine risk on site (nobody is being tracked) from an ordinary network hiccup (data is accumulating and will arrive later). Without that distinction, every network fluctuation turns into an alarm, and managers lose the ability to notice the failures that actually matter.

The bottom line

What happens if the field app is force-quit shouldn't be treated as a failure to prevent — it's a reality to manage: phones die, batteries run out, users revoke permissions by accident. What matters is making sure that moment never goes unnoticed. An automatic five-minute check, two-sided notification, and a resolution step left to the manager keep an outage from quietly leaking into the timesheet.

If you'd like to review how often these gaps show up on your own field team and how they're currently being tracked, take a look at HR-Tech's field tracking and timesheet module, or reach out through our contact page and we can walk through your current process together.