# Recover a missing or rejected clock action

For the employee and shift leader. First confirm employee, location, original
clock-in/out time, and which till was used. Scheduled shifts do not establish
that a clock action was recorded.

## Saved on the till and waiting to sync

Restore the till's connection. Keep the original device and its pending actions
intact. Check **Console → Team → Time tracking**, selecting the correct location
and date range, then **Search**. A local On shift status is not proof that the
central record has been saved.

Do not repeatedly clock in, create a manual record, sign out, reinstall, or
clear device data while the pending action is unresolved. A later sync can
otherwise duplicate the replacement.

## Time records need review

The app preserves rejected original times on the till. Ask the manager to
compare the displayed clock-in/out with central time records before retrying.
Check for an existing matching record, an active record, an already completed
shift, or a conflicting manual correction.

Use **Retry sync** with a connection only after that review. The app reports
when a retry could not start and retains the saved times. If the central record
already reflects the work, have support resolve the rejected local action; do
not create another clock event to hide the warning.

## Someone forgot to clock out

Agree the actual finishing time with the employee and shift leader. Locate the
active record, review overnight dates, and use the authorised edit workflow in
[Time tracking](/staff/time-tracking). Verify the saved end time and duration.
Do not set a guessed time or delete the record merely to let daily closing
proceed.

## Escalate

Keep the employee and time-record references, working location, original times,
affected till, queue/rejection status, central state checked, and exact error.
Use the authorised support channel for personal records and keep staff PINs out
of screenshots. Continue the restaurant's agreed time-record fallback while the
discrepancy is reviewed.