Working offline

Trackapt keeps working with no signal. A form filed or a figure broadcast without a connection is saved on the device and sent once there is one.

This exists because of where the work happens. Readings are taken where the readings are — down a shaft, at a weighbridge, on a haul road — and those are exactly the places without coverage. The figures were never the app's to lose.

What queues

Action	Queues offline?
Filing a form entry	✅
Broadcasting a figure	✅
Importing a survey pickup (Mining)	✅ with the surface it joins or starts
Approving or declining a mine plan (Mining)	✅
Selling at the retail till	✅ (its own queue)
Reading a screen	✅ served from the copy on the device
Anything whose result you must act on immediately	❌

That last row is the honest limit: a queued write gets no answer back from the server, so anything that needs the saved document's own identity — its number, for instance — needs you online at the time.

Seeing what is waiting

The app shows what is queued, newest last, with what each one is — the form and the date it covers, so a row reads as Daily Production · 15 Aug 2026 rather than as an opaque pending item.

A queued write is removed only once the API has accepted it. Nothing disappears from the queue on the strength of having been attempted.

How it gets sent

Two routes, and both are needed:

In the background, without the app open. The browser wakes Trackapt when connectivity returns and sends the queue. This is the route that covers the case that actually happens: an operator files a form, pockets the phone, and never reopens it.

When you open the app, or when the device comes back online. Safari and every browser on iOS have no background sync at all, so for a large share of field devices the first route does not exist. This one covers them.

Both read the same queue, so a write sent by one is gone before the other looks at it. A device that queues forty readings down a shaft wakes once on reconnection, not forty times.

The one way work is still lost

The queue lives on the device that took it

Nothing is on the server yet, so nothing else can send it. Two things destroy it, and neither is an accident you can have by mistake:

• Clearing the browser's site data for Trackapt, or running a browser set to clear it on exit. Never work from a private or incognito window — that throws the storage away when the window closes.
• The device never coming back — lost, wiped, replaced.

If a device is going out of action for a while, get its queue to clear first, from anywhere it has a connection.

On a shared device

The queue is filtered to the signed-in person. The next person to sign in on a shared tablet sees their own queued work and not their colleague's — they cannot read which shifts somebody else filed, and cannot discard work they have no way to send.

This is why signing out at the end of a shift matters on a shared device, and why anything still queued should be sent before you hand it over.

Filing a backlog is safe

Trackapt orders entries by the period they cover, never by when they were typed. A week of paperwork entered on Friday sits in the right days, and a backdated entry cannot present itself as the most recent.

The other way to work offline

Download the form as a spreadsheet, fill it in, and upload it back. See Filling a form from a spreadsheet.

Use the workbook where somebody else is doing the keying, or where the figures already live in Excel. Use offline filing where the person capturing is the person holding the app.