How offline time tracking works

Any team with people on trains, planes, client sites or unreliable home connections will eventually lose tracking data — unless the tool was designed for it. Offline tracking is one of those features nobody evaluates until the week it costs them a day of billable hours.

What a tracking agent is doing

A desktop agent continuously produces small records: session start and stop, the foreground application, activity samples, idle transitions. Online, these are batched and posted to the server every few seconds or minutes.

When the network disappears, there are three possible designs, and only one of them is acceptable.

Stop tracking

The worst option. Hours are simply lost, and the employee finds out at the end of the week.

Buffer in memory

Better, until the laptop sleeps, the app is closed or the machine restarts — at which point the buffer is gone.

Persist to local storage

The correct approach. Records are written to a local database on disk immediately, marked as unsynced, and survive reboots. This is what "offline support" should mean.

Reconciliation on reconnect

When the connection returns, the agent has to merge a backlog into a server that has moved on. Several things have to be handled:

• Ordering — records are replayed in the order they occurred, not the order they uploaded
• Deduplication — a partially-sent batch must not create duplicate sessions
• Clock skew — the device clock may be wrong, so records carry a monotonic counter alongside the timestamp
• Overlap — a session running past midnight has to be split correctly for daily reporting
• Conflicts — if a manager edited the same day manually, one version has to win by a stated rule

Deduplication is where most implementations break. A batch that reached the server but whose acknowledgement was lost will be retried, and without idempotency keys you get the same hour billed twice.

Limits worth knowing

• Local caches are bounded — typically days, not months. A machine offline for a fortnight may drop the oldest records.
• Screenshots are large. Many tools cache metadata offline but discard image captures.
• A live dashboard cannot show offline work. Expect a gap until that person reconnects.
• Time zone changes while travelling are a common source of misattributed days.

What to test before you rely on it

Do not take the feature list at its word. Run this in an afternoon:

• Start a timer, disable networking, work for thirty minutes, reconnect — is the time there?
• Repeat, but reboot the machine before reconnecting — is it still there?
• Repeat across a time zone change if your team travels
• Check whether the reconnected session is flagged in reports as offline-captured
• Confirm no duplicate entries appear after two consecutive syncs

Why the flag matters

Offline-captured time is genuine but unverified in real time. A good system marks it as such. During a client billing dispute, being able to distinguish continuously-verified hours from reconciled offline hours is the difference between a short conversation and a long one.

Monicrew caches sessions locally, replays them in order with idempotent sync, and flags offline-captured blocks in reports so the distinction is visible where it matters.