timesheet
Two people on the team have been finishing late for three weeks. Nobody has complained, the work is going out, and the only reason anyone noticed is that one of them mentioned it in passing. The obvious response is to start tracking overtime, and every product in that category will happily record it. Six weeks later there is a clean report showing exactly how much extra those two people worked, which is useful for payroll and arrived far too late to change anything.
That gap is the whole subject. Recording overtime and preventing it are separate jobs with separate tools, and the search results for this term almost all answer the first one.
The first problem is a record. Hours worked, by whom, on which day, kept in a form that survives a payroll dispute or an audit. It is backward looking by definition, it has to be accurate rather than approximate, and in many jurisdictions keeping it is not optional.
The second problem is a signal. Somebody needs to know on Wednesday that next week's assignments already exceed what the week contains, while there is still time to move a task or push a date. This is forward looking, it can be rough, and it depends on planned work rather than recorded work.
A time clock cannot produce the second one, because the data it needs does not exist yet. Nobody has worked next week. The only inputs available are the tasks that have been assigned, the dates they are due, and some estimate of how long they take. Those live in whatever tool holds the work, not in the tracker.
Teams that buy a tracker expecting a warning system end up with a very precise history of the problem. The record and the signal come from different places, and a team that needs both has to decide where each one lives rather than hoping one product covers it.
In the United States, the federal floor is set by the Fair Labor Standards Act, and the Department of Labor states the rule in one sentence: covered employees must receive overtime pay for hours worked over 40 in a workweek at a rate not less than time and one-half their regular rates of pay.
Three details in the official guidance matter more than the headline.
There is no cap on hours. The Act contains no limit on the number of hours employees aged 16 and older may work in any workweek. Overtime is a pay obligation, not a permission system, so a tracker that blocks entries past a threshold is imposing a policy rather than a legal rule.
Weekends are not special. The guidance is explicit that the Act does not require overtime pay for work on Saturdays, Sundays, holidays, or regular days of rest, unless overtime is worked on such days. A team that assumes weekend hours automatically attract a premium is thinking of a contract or a state rule, not the federal one.
The unit is the workweek, not the day. A ten hour Tuesday followed by a six hour Wednesday produces no federal overtime at all. Some states and many countries do count daily thresholds, and several countries apply monthly caps rather than weekly multipliers, which is the practical reason any tracker under consideration must let the threshold, the period and the multiplier be configured rather than assuming one rule. A team with staff in more than one jurisdiction should check that the tool supports different rules per person before trusting a single total.
The category is mature and the free tiers are genuinely usable, which is worth knowing before anyone builds a spreadsheet.
Jibble is free to use for unlimited users, with mobile and web clock-ins, desktop tracking, basic timesheets, and integrations including Slack, Microsoft Teams and QuickBooks. Its own description of the output covers what payroll needs: regular hours, overtime, paid breaks and paid time off, calculated before the data is exported.
Clockify takes a different shape. Its free plan includes unlimited tracking across a timer, timesheet, calendar and automatic tracker, with apps, integrations, reports and support, capped at five team members. Paid tiers start at 4.99 US dollars per user monthly, or 3.99 paid annually, and the setting most teams want, time approval, sits on the Standard plan at 6.99 monthly or 5.49 annually, alongside time off management. Scheduling appears on Pro at 9.99 monthly or 7.99 annually.
My Hours follows the same pattern with a free tier limited to five active users, then Basic at 5 US dollars per user monthly or 4 annually, and Pro at 9 or 8. Approval workflows, granular permissions and extended audit logs are paid features there too. Toggl Track's free plan also covers up to five users.
The pattern is consistent enough to plan around. Recording hours is free or nearly free. Approving them, restricting who can edit them, and keeping an audit trail of changes is what the money buys, and those are exactly the features that turn a record into something that can be shown to a client or an auditor.
Accept that the record is solved. The warning still is not, and the reasons are structural rather than a matter of product quality.
A tracker knows how long something took. It does not know what is coming. Next week's overtime is decided by this week's assignment decisions, and those happen in the task tool, in a planning meeting, or in a chat message that reassigns a card. By the time the tracker has data, the decision is three weeks old.
A tracker also sees hours without seeing commitments. Forty hours logged looks identical whether the person is comfortably finished or holding four open tasks that all land on Friday. The number that predicts overtime is not hours worked, it is assigned work remaining divided by the days left, and the tracker holds neither term.
Dashboards do not close the gap either. Real time overtime charts are real time about the present, which is still too late. The useful question is about a week that has not started.
There is a human factor on top of the arithmetic. A person heading for a sixty hour week usually knows, and the reason they do not raise it is rarely that the data was unavailable. Making the load visible in a place the whole team already looks does more than any private alert, because it turns a personal admission into a shared scheduling fact.
The forward view does not need a new product. It needs three fields on work that already exists.
An owner. Unassigned work is invisible load. Every task that will be worked next week needs a name against it, even provisionally.
A date. A due date or a scheduled window. Without it there is no week to sum into.
A rough size. Hours, or a size category that maps to hours. Precision is not the point. The difference between a two hour task and a two day task is what makes the total meaningful, and estimates within a factor of two are enough to spot a week that holds fifty five hours of work for one person.
With those three, the calculation is trivial: group next week's tasks by owner, sum the sizes, and compare each total with the hours that person actually has after meetings. Most task tools will do this with a custom numeric field and a grouped view, and a board where estimated hours sit on the card as a custom field alongside the assignee gives the sum without exporting anything.
Two thresholds are worth agreeing in advance. The first is the point at which a week is considered full, which is always lower than the contracted hours, because meetings, support and interruptions are real work that rarely carries a card. The second is the point at which something has to move rather than be absorbed. Naming both in advance turns an awkward conversation into a rule that was agreed when nobody was under pressure.
A signal nobody can act on becomes noise within a month, so it is worth deciding in advance what the response is. There are only four levers, and three of them are uncomfortable.
Move a date, which is the cheapest option and the one that requires telling somebody outside the team. Cut the scope of a task, which usually means shipping a smaller version rather than dropping it. Reassign work, which only helps if the receiving person has genuine slack and the task is not tied to one person's knowledge. Or accept the overtime deliberately, with an end date and something given back, which is a legitimate choice for a launch week and a slow disaster as a standing arrangement.
What does not work is leaving the total visible and doing none of the four. The team learns that the number has no consequences, estimates drift upward or downward depending on temperament, and the signal stops describing anything. Deciding which lever gets pulled first, before the first overloaded week appears, is what keeps the number honest.
| What is needed | Where it has to come from | Typical cost shape |
|---|---|---|
| Legal record of hours worked | A clock-in or timesheet tool, or a timesheet feature on the work itself | Free for a small team in several products |
| Overtime calculated by a configurable rule | The same tool, provided the threshold and period can be set per person | Usually free, but check multi-jurisdiction support |
| Submission and approval with an audit trail | A paid tier, or an add-on | The main thing a subscription buys |
| A forward view of next week's load | The tool that holds the tasks, with owner, date and size | Included where custom fields are |
| One place where hours and tasks agree | A single tool covering both, or a reconciliation routine | Either a bundled price or somebody's monthly hour |
The last row is the one that decides most cases. Hours in one product and tasks in another means project names have to be mapped between them, a person has to explain the difference at month end, and the forward signal has to be assembled by hand because neither system holds both halves. For a team of five that is a tolerable annoyance. For a team of twenty it becomes a role.
Teams already paying per person for a task tool should check whether timesheets and approval exist there as an add-on rather than a second subscription before comparing standalone trackers, because the bundled route usually removes the reconciliation work along with the second bill. Where a tracker is already embedded in payroll and working, the better move is to leave it alone and build only the forward view in the task tool.
Put a rough hours estimate on every task assigned for next week, then group next week by owner and read the totals out in the planning meeting. That single number, before the week starts, does more than any report of last month's overtime. If the tasks currently have no owner or no size, fixing that is the prerequisite, and the setup steps for a board that carries both take less time than evaluating a tracker.
No. It records what happened, which is what payroll and any audit require, and the report arrives after the decisions that caused the hours. Preventing overtime depends on seeing assigned work against available time before the week begins, and that calculation needs owners, dates and rough sizes on the tasks rather than a clock.
The Fair Labor Standards Act requires overtime pay for hours worked over 40 in a workweek, at not less than time and one-half the regular rate of pay, for covered employees. The Act sets no limit on how many hours an employee aged 16 or older may work, and it does not require a premium for Saturdays, Sundays or holidays unless overtime is worked on those days. State rules and other countries add daily thresholds and other conditions, so any tool needs configurable rules.
For recording, often yes. Jibble is free for unlimited users and calculates regular hours, overtime, breaks and paid time off, and Clockify, My Hours and Toggl Track each offer a free tier for up to five users. What the free tiers generally exclude is approval, granular permissions and an audit trail of edits, which are exactly the parts needed once the hours are shown to a client or an auditor.
A size category is enough, as long as it maps to a rough number of hours. Grouping next week's tasks by owner and summing those numbers finds an overloaded week reliably, because the errors are small compared with the difference between a full week and a fifty five hour one. Estimating only the work scheduled for the next two weeks keeps the habit sustainable.
It removes a reconciliation step, which is the main practical argument. When hours sit on the card being worked, the record and the plan share one set of names and one set of owners, and the forward view comes out of the same data. Where a separate tracker is already tied into payroll, the sensible split is to leave the record where it is and build the forward view where the tasks live.