You Forgot to Track Your Time. Here's How to Rebuild the Week
A method for reconstructing hours without inventing them
Everyone who tracks time forgets to track time. The timer that never started, the one still running since Tuesday lunch, the afternoon that disappeared into an incident. The question is not whether it happens, but what you do on Friday when a timesheet is due and Wednesday is blank.
What follows is a method rather than a trick: work from artifacts instead of memory, bracket what you can actually show, label what you estimated, and then change one thing so next week needs less of this.
First, decide how exact this has to be
Before reconstructing anything, be clear about what the number is for. Hours you are billing a client are a claim about work you did — reconstruct them conservatively, and where there is real doubt, round down. Hours you log for your own curiosity can be a reasonable estimate. Hours going into a payroll or compliance system have rules that are not yours to reinterpret: ask what they are.
One rule covers all three. Never invent precision. "3.75 hours" reconstructed from memory reads like a measurement and isn't one. If you estimated, say so — in the entry's description if the tool has one, or in the note that travels with the invoice.
Five artifacts that remember better than you do
Your calendar
Start here. Meetings, calls and blocked focus time are timestamped by definition, and they set the day's skeleton: if a 10:00 call happened and a 14:00 call happened, the middle is bounded even when it is unlabelled.
Document and file history
Anything with revision history — a shared doc, a design file, an editor's local history — gives you edit timestamps. A document first touched at 11:05 and last saved at 11:52 is good evidence of a working session, though it is not proof you were present for all 47 minutes.
Version control
For anyone who writes code, commit history is the best surviving record of the day, and there are tools built for exactly this reconstruction. git-hours estimates working hours by measuring the gaps between commits and grouping them into sessions when the gap falls under a threshold. The Python tool hourly goes further, parsing explicit clock-in and clock-out keywords out of commit messages. If you would rather install nothing, git log with an author and a date range gives you the raw timestamps to bracket by hand.
Messages, tickets and reviews
Chat messages, ticket transitions and review comments are timestamped and usually say what you were doing. A ticket moved to "in review" at 16:40 dates the end of that work precisely.
Sent mail
The sent folder is a timeline of decisions. A proposal that went out at 15:20 puts the writing of it somewhere before 15:20.
One technique gets repeated a lot and deserves a caveat: mining your browser history. It is good for jogging memory and weak as a record — background tabs, research rabbit holes and things you opened and abandoned all look identical in the log. Use it to remember, not to justify.
Turn artifacts into entries
The method is bracketing. For each block of work, take the earliest artifact as the start and the latest as the end, then subtract the gaps you can see — a 45-minute hole with nothing in it is a break, not deep work. Then run two sanity checks.
•
Does the day total plausibly? A reconstructed eleven-hour Wednesday is usually two hours of double counting: the same work left traces in three systems.
•
Would you defend each block to the person paying for it? If the answer is no, cut it.
Round to something honest. Fifteen minutes is a fine grain for reconstructed work; pretending to the minute is not. If you need to add the blocks up across a week, the
timesheet calculator takes clock-in and clock-out rows, and the
hours calculator adds and subtracts loose durations without a spreadsheet.
Doing it in TickTappy
TickTappy assumes you will get the timer wrong sometimes, so the repair paths sit close to the surface.
•
The quick fix. Right after you start or stop a timer, a quick-adjust button appears — about fifteen seconds after a start, ten after a stop, fading out as the window closes. Tap it and you can move the start time back to when work really began, or move the stop time — the case where you noticed twenty minutes after stopping.
•
The full adjust dialog. Any entry in the entries list can be opened and edited: start date and time, end date and time, or deleted outright if it should never have existed.
•
Add Entry. For work that was never timed at all, create the entry from scratch — pick the tag, set the start and end, done.
•
Add series. For the same block repeated across days, such as the retainer morning you forgot three days running, a series creates one entry per day across a date range at the same wall-clock times, with a weekdays-only option.
What TickTappy does not do, so the seam is visible: there is no CSV export today. Reconstructed totals are read in the app's day and week summaries rather than dumped into a spreadsheet, which is fine for a personal record and worth knowing about if your week ends in an invoice. The
freelancer use case page is honest about the same gap.
Make next week need less of this
Review at the end of the day, not the end of the week
Every source that treats this seriously lands in the same place: correct entries while the day is still in your head. Two minutes at 17:00 beats an hour of forensics on Friday.
Fewer tags, bigger buttons
People forget to start timers when starting one requires a decision. If your tag list needs thought — which project is this, really? — it is too long. Five tags you press without looking beat twenty that are technically more accurate.
Make the running timer visible
A lock screen Live Activity, a watch complication or a home screen widget turns "is it running?" into a glance. Most forgotten stops are simply invisible timers; see
Apple Watch time tracking for the wrist version of this.
Or let something else do the remembering
There is a different school of thought. Rather than reconstructing, capture passively: Timely is described in reviews as rebuilding a day from device and app activity automatically, and Timesheet's own documentation leans on NFC tags, geofences and beacons so entries start without a decision. Both trade something — privacy in the first case, setup in the second — for reliability, which is a fair trade for some people and not for others.
Track it as it happens instead
TickTappy starts with one tap on a coloured tag and stops with another. Free core, no account, works offline.
Frequently asked questions
How do I reconstruct hours I forgot to track?
Work from artifacts rather than memory: calendar events, document and file revision history, version control commits, ticket transitions and sent mail. Bracket each block between the earliest and latest artifact, subtract visible gaps, round to fifteen minutes, and label the entry as reconstructed.
Is it acceptable to estimate hours on a client invoice?
Estimating is normal when a timer was missed, but the estimate should be conservative and disclosed. Round down where you are unsure, and say in the invoice note that those hours were reconstructed rather than timed. Never present an estimate at a level of precision it cannot support.
Can I add a past time entry in TickTappy?
Yes. Add Entry creates an entry from scratch with any start and end time, the adjust dialog edits or deletes an existing one, and Add series creates the same block across a range of days, with an option to skip weekends.
What is the quickest way to fix a timer I started late?
In TickTappy, use the quick-adjust button that appears right after you start or stop — roughly fifteen seconds after a start and ten after a stop. It moves the start or end time without opening anything else. Once that window closes, open the entry in the entries list and edit its times there.
How do developers reconstruct coding time?
From commit history. git log filtered by author and date gives raw timestamps; git-hours groups commits into sessions using the gaps between them; and the Python tool hourly reads explicit clock-in and clock-out markers out of commit messages.
Also see
Sources