Staff TrackerStaff GPS troubleshooting: stale locations and missing updates
Diagnose a staff phone that stops updating by checking identity, timestamps, connectivity and background behaviour in a controlled order, then verify the result on a realistic journey.
Describe the symptom before changing settings
“GPS is not working” can describe several different problems. The phone may be unable to obtain a location, the client may not be sending reports, the service may not be receiving them under the expected identity, or the coordinator may be interpreting an old observation as current. Each problem needs a different check.
Write down the visible symptom first. Include the time of the latest observation, whether the phone reports with the app open and whether the map position is missing, stale or implausible. This simple description prevents troubleshooting from becoming a series of unrelated changes.
Do not begin by reinstalling everything. Reinstallation can remove useful context and introduce a new configuration error. Establish what is working and where the sequence appears to stop. A controlled investigation usually produces a clearer resolution and a better support record.
Check that you are looking at the intended device
Confirm the staff assignment and the phone currently in use. A replacement handset, shared device or duplicated identifier can make reports appear under the wrong person or alternate between places. In that situation, the location system may be receiving information correctly while the identity arrangement is wrong.
Compare the configuration with the connection instructions in the Staff Tracker workspace. Do not paste private connection details into a public support forum. If a support person needs those details, use the approved private channel and share only what is relevant to the issue.
Check whether an old phone is still active. A retired device left charging at a depot can create confusing observations if it shares an assignment with the replacement. Resolve the device ownership and identity before investigating accuracy or reporting frequency.
Establish a fresh foreground observation
Place the phone somewhere suitable for an ordinary location test and confirm it has network access. Open the client, follow the workspace instructions and observe whether a new timestamp reaches the dashboard. The important result is a fresh report, not merely a familiar pin remaining visible.
If the location does not update, check the obvious conditions individually: whether location services are available, whether the app has the required permission and whether the connection configuration matches the workspace. Use the current Traccar Client troubleshooting guide for platform-specific checks.
After each change, repeat the same simple test. Keeping the conditions comparable makes the result interpretable. If three settings change and reporting resumes, you still do not know which change was necessary or whether one introduced an avoidable trade-off.
Compare foreground and background behaviour
If the phone reports while the app is open, lock the screen and repeat a short journey. Ask the coordinator to watch for a new observation without asking the worker to reopen the app every few seconds. This distinguishes basic connectivity from the way the device behaves during normal background use.
Background operation depends on the phone's platform, permissions and restrictions. Menu names can vary across operating-system versions and device manufacturers, so do not rely on an old screenshot as the final authority. Follow current platform guidance and the instructions relevant to the installed client.
Record the difference precisely. “Fresh locations arrive while open but not during the locked-screen test” is a useful finding. It narrows the investigation without pretending to establish a specific cause before the relevant controls have been checked.
Separate poor accuracy from stale information
An old accurate point and a fresh imprecise point are different problems. A stale location means the latest available observation is not recent enough. An accuracy issue means the reported position does not represent the expected location closely enough for the operational purpose.
Check timestamps before judging the pin's position. If the phone has not reported since the previous site, its apparent distance from the current workplace may simply reflect age. If the point is fresh but moves around near a boundary, review the physical environment and the site's tolerance for uncertain observations.
A phone inside a large building may produce a different quality of location estimate from the same phone outdoors. Do not interpret a small displacement on the map as proof of movement without supporting context. For attendance, test whether the overall boundary and reporting sequence work reliably enough for the site's purpose.
Investigate a problem affecting one site
When several phones behave poorly at the same workplace but normally elsewhere, examine the shared conditions. Covered entrances, indoor work areas and connectivity limitations may be relevant. The geofence may also be positioned around the wrong entrance or exclude the normal arrival route.
Run a controlled journey with one known device: start outside, enter through the usual route, remain on site and leave. Compare the received observations with the actual route. If locations arrive but the attendance transition is missing, investigate the boundary instead of treating the client connection as the only possible cause.
Document any recent site change. Temporary building works, a new staff gate or a relocated parking area can explain why a configuration that previously worked now produces exceptions. Include the site owner in the investigation so the technical setup reflects current operations.
Investigate a problem affecting one phone
If the same phone goes stale across several sites while others work normally, focus on the device's setup and operating conditions. Confirm its assignment, client configuration and relevant permissions. Ask whether the issue began after a replacement, reinstall or operating-system change.
Compare a short foreground test with a background test and a normal work journey. Keep notes on when reporting stops or resumes. Avoid collecting unrelated personal information from the device; the useful evidence concerns the reporting behaviour and the settings relevant to it.
If a setting change appears to help, verify it over a representative period. A single successful point immediately after reopening the app does not establish that the background problem is resolved. The follow-up should reproduce the situation that originally failed.
Consider battery use without changing everything
A phone must remain usable for the shift, so battery behaviour belongs in the pilot and support process. Record the device's starting charge, the approximate period of use and other relevant workload rather than attributing all battery consumption to tracking automatically.
Before changing reporting settings, define the minimum useful operational result. A team may need reliable site transitions and reasonably recent travel observations, not the densest possible stream of points. Consult the Traccar configuration guide for the meaning of the available controls, then test a deliberate change.
Do not promise that one interval or accuracy setting will provide the same battery life on every phone. Hardware, operating conditions and other activity vary. Use representative devices and compare similar work patterns when judging whether a configuration is practical.
Example: updates resume when the app is opened
A supervisor notices that one staff phone sends a fresh point whenever its user opens the client, then appears stale again later. The phone's assignment and connection details are correct, and a foreground test succeeds. The team therefore focuses on the background test rather than repeatedly changing the server address.
They review the device's relevant permissions and restrictions using current guidance, adjust the identified setting and repeat the locked-screen journey. They then check the behaviour during an ordinary shift. Only after that follow-up do they record the issue as resolved.
The important lesson is the sequence: describe, isolate, change one thing and reproduce the original conditions. This illustrative example does not claim that the same setting explains every background-reporting problem.
Know when to escalate
Escalate when the basic checks are complete but the behaviour remains unexplained, or when a change requires expertise beyond the supervisor's role. Provide a concise record of the symptom, device and client versions, test times, configuration checks performed and the result of each test.
Avoid sending a broad collection of screenshots without explaining the question. A support person needs to know what should have happened and what actually happened. Remove unrelated personal details and use the approved channel for information that cannot safely be shared publicly.
While the technical issue is open, keep the operational fallback active. Staff should know how to report attendance or availability through the agreed process. An unresolved phone problem should not leave a supervisor guessing about the current work arrangement.
Troubleshooting record template
- Expected behaviour: the update or attendance event you intended to observe.
- Actual behaviour: the latest timestamp and the specific difference.
- Scope: one device, several devices or one workplace.
- Tests: foreground, locked screen and representative journey.
- Changes: one recorded adjustment at a time.
- Verification: evidence that the original failure no longer occurs.
- Follow-up: owner and next check if the cause remains uncertain.
Frequently asked questions
Should we reinstall the app first?
Usually begin with identity, timestamps and the simplest connection checks. Reinstallation can remove context and create new setup work. Use it when the investigation or support guidance gives a reason, then verify the full setup again.
Why is the pin at yesterday's workplace?
Check whether the observation is old. A stale point can remain the latest known information after reporting stops. Confirm current circumstances through the fallback channel and investigate why no fresh report is arriving.
How do we tell a site problem from a phone problem?
Compare patterns. Several devices failing at one workplace suggest checking shared site conditions and boundaries. One device failing across workplaces suggests checking that device's configuration and behaviour.
What proves a fix worked?
A successful test under the conditions that originally failed, followed by representative normal use. A fresh point immediately after opening the client is useful evidence, but it does not by itself prove reliable background reporting.