Wintertrace On GitHub →

Snow service time tracking

Time tracking for snow service, by the shift and by the customer

Wintertrace records the shifts behind every operation. Total shift hours, time per customer, time per operation, standby time — captured automatically while the operator runs the documentation flow they would run anyway. CSV export goes straight to payroll.

Why snow service time tracking is its own problem

A typical office time-tracking tool assumes one long task per day, started and stopped at the desk. Snow service runs on a different rhythm — long shifts of short tasks, pre-positioning time before the first operation, travel between sites, standby time during gaps in conditions, and a closing routine after the last customer.

The hours that need to be captured are not just the operation hours; they are the whole shift. The operation records describe what was done. The shift record describes the time inside which those operations happened.

Four time-tracking challenges, and the answer

The shift starts hours before the operation

A driver may be on the road at 03:00 to be ready for the first operation at 04:00. Capturing only the operations leaves the hour of pre-positioning untracked — and unpaid in many payroll models. Wintertrace separates shift time from operation time so both are visible.

Multiple short jobs across one shift

A typical winter shift is not one long task — it is six or eight short operations, often with travel in between. Tracking total hours, productive hours, and per-customer time at the end of a shift is tedious to do by hand. The structured shift record handles it.

Standby time has its own rules

Some contractors pay standby differently than active time. Wintertrace can record a shift as "open but with no operations" — the standby state is visible without inventing fake operations to capture the hours.

Payroll cycles want clean exports

A spreadsheet of "driver, date, shift start, shift end, hours, operation count" is what payroll usually wants. CSV export covers that directly; the underlying database is available for anything more custom.

What gets recorded per shift

The structured fields behind every shift record. Each is part of the database, available for reports and CSV export.

Shift open and close
Stamped from the device clock the driver uses to start and end the shift.
Total shift duration
Computed automatically; available as a column in the analytics view.
Operations inside the shift
Each operation with its own open and close times, customer, and site.
Time between operations
Implicit in the timeline; useful for analysing travel and standby patterns.
Driver identity
The driver account, the equipment used where relevant, and the shift number.
Notes per shift
Free-text notes for anything the structured fields do not cover — vehicle issues, weather observations, route changes.

From shift records to reports

Four output shapes operators end up needing.

Per-driver monthly hours

Total shift hours per driver per month. Productive-hours-only column where the operator wants to distinguish.

Per-customer hours and operations

Useful for contracts that bill by hour or that need monthly evidence of service density.

CSV for payroll systems

Standard CSV with the fields most payroll systems consume directly. Custom columns can be added through the structured database.

Audit trail

Every shift state change is recorded with timestamp and actor. Late edits or corrections leave traces.

Time-tracking questions

Does Wintertrace replace a dedicated time-tracking app?

For winter service shifts, in most cases yes. The shift records capture open, close, operations within, and driver identity. For contractors with significant non-winter work or complex multi-job-site time accounting, a dedicated time-tracking tool may still be the right choice — and CSV exports from Wintertrace can flow into it.

Can drivers edit their own shift records?

Open and close timestamps are stamped from the device clock and locked once a shift closes. Notes can be added; corrections to timestamps require a separate workflow visible in the audit log. The structure prevents quiet post-shift edits.

How does Wintertrace handle overnight shifts?

Shifts that span midnight are handled as one record from open to close. Daily reports split the hours across calendar days automatically; monthly reports aggregate normally.

What about standby pay and waiting time?

A shift can be open without operations attached — that is the standby state. Hours are still recorded. The distinction between active and standby time is visible in the report. How those hours map to payroll is the operator policy.

Can the CSV be customised?

The default CSV covers the common payroll cases. The underlying database is fully accessible to the operator, so custom CSV layouts can be generated with standard SQL tools when needed.

Is GPS data part of time tracking?

GPS data is recorded against operations, not against the whole shift. Travel time between operations is implicit in the shift timeline. Operators who want a per-minute GPS record of the entire shift would need a different tool — Wintertrace's GPS scope is the operation window, not full surveillance.

How are corrections handled?

Through a separate correction workflow that records the original value, the corrected value, the actor, and the timestamp. The audit log makes it visible. Honest correction is supported; quiet alteration is not.

Source code on GitHub. Free under GNU AGPLv3.

Try Wintertrace.

Upload one small file to your web hosting, open it in your browser, and the installer puts the latest signed Wintertrace core on your webspace. About ten minutes — no FTP client needed.

install.php · Ed25519-signed core · GNU AGPLv3

Read the installation guide →