To fix a missed week of time tracking, mine your digital footprints — git logs, calendar events, browser history, and Slack messages — then fill the remaining gaps with structured estimation. Most developers can rebuild an accurate timesheet in under 30 minutes.
It is Friday at 4:30 pm. Your manager pings you: timesheets are due by five. You open the tracker. Every row is blank. Monday through Thursday is a void. You know you worked — the code is in production — but you cannot remember what happened on which day, or for how long.
Do not panic. You left a trail. Every commit, meeting invite, Slack message, and browser tab is a timestamped breadcrumb. This guide covers five emergency recovery methods to reconstruct your week, plus how to make sure this never happens again.
Emergency Recovery Method 1 — How Do You Reconstruct Time from Git Logs?
Your git history is the most reliable record of your work week. Every commit carries a precise timestamp, a branch name, and a message. Unlike your memory at 4:30 on a Friday, git does not forget.
Pull your weekly activity
Start with this command:
git log --author="Your Name" \
--since="last Monday" \
--until="now" \
--format="%ai | %s" \
--allThe --all flag is critical. Without it, you only see the current branch — and every commit you pushed to feature branches, hotfixes, or experiments disappears. For more on this approach, see the full guide to reconstructing timesheets from git.
Span multiple repositories
Most developers touch several repos in a week. Loop through all of them:
for repo in ~/work/*/; do
cd "$repo"
git log --author="Your Name" --since="last Monday" \
--format="%ai|$(basename $repo)|%s" --all
done | sortSorting by timestamp gives you a single chronological view of your entire week.
Convert commits into time blocks
Commits mark the end of a session, not the beginning. To estimate duration, look at the gap between consecutive commits. A common rule of thumb: if two commits are less than 30 minutes apart, they belong to the same work session. If the gap is wider, a new session started.
For each session, record the start time (previous commit or session start), end time (last commit), and the project (derived from the branch name or repo). Round to 15-minute blocks for your timesheet.
Know the limits
Git only captures time you spent writing code. It misses meetings, design discussions, code reviews without commits, and those long debugging sessions where you stared at a stack trace for an hour before changing one line. That is why git alone recovers roughly 70-85% of a developer’s real working time. You need the next methods to fill the rest.
Emergency Recovery Method 2 — How Do You Use Calendar Events to Fill Gaps?
Your calendar is the second pillar of timesheet reconstruction. Every meeting, standup, retro, and one-to-one has a start time, end time, and subject line. That is more metadata than most people record manually.
Export your calendar
Most calendar applications let you export a week’s events as a CSV or ICS file. You can also pull events programmatically:
- Google Calendar: export via Settings or use the Calendar API
- Outlook: File > Open & Export > Import/Export
- Apple Calendar: File > Export
What you need from each event: the title, date, start time, end time, and any project reference in the description.
Cross-reference with git
Layer your meeting times over your git commit timeline. This reveals the shape of each day. A morning standup at 9:15, three commits between 10 and 12, a client call from 1 to 2, four more commits until 5 — suddenly Monday is no longer a blank.
For a deeper walkthrough on merging calendar data with your timesheet, see the guide on backfilling timesheets from calendar data.
Watch for hidden time sinks
Meetings expand. A 30-minute slot often runs to 45 minutes. If your calendar says a meeting ended at 2:00 but your next commit landed at 2:35, the gap probably includes post-meeting notes, follow-up messages, or context switching. Account for that in your time entries rather than leaving a mysterious 35-minute hole.
Emergency Recovery Method 3 — How Do Browser History and Slack Messages Help?
Git and calendar cover code and meetings. But what about the research, documentation reading, ticket triage, and team communication that filled the gaps? Your browser history and messaging tools have the timestamps.
Browser history
Open your browser history and filter by date. Each visited URL has a timestamp. You will see patterns:
- A cluster of Stack Overflow and documentation pages signals a debugging or research session
- Internal wiki and Confluence visits suggest documentation or planning work
- Ticket tracker pages (Jira, Linear, Asana) show when you were triaging or updating stories
Most browsers let you search history by date. In Chrome, visit chrome://history and use the date filter. In Firefox, open the Library and filter by day.
Slack and messaging tools
Your Slack messages carry precise timestamps. Scroll through each channel you posted in during the week. Pay attention to:
- When you asked or answered technical questions (coding work)
- Client-facing channels where you shared updates (client work)
- Thread activity that maps to specific tickets or projects
You do not need to log every message. The timestamps give you anchor points: “I was discussing the API migration in #backend at 3:15 on Tuesday, so I was working on Project X at that time.”
Email sent items
Your sent folder works the same way. Each outgoing email is a timestamped record of what you were doing. Filter your sent items by date and scan the subjects. Internal project emails, client responses, and review feedback all map to billable categories.
Emergency Recovery Method 4 — How Do You Estimate Time for Remaining Gaps?
After mining git, calendar, browser, and messaging data, you will have 80-90% of your week accounted for. Gaps remain. Here are three structured estimation techniques to fill them honestly.
The block method
Divide each day into morning (9-12), afternoon (1-5), and any overtime blocks. For each block, ask: “Do I know what I was working on?” If yes, assign it. If not, look at the tasks you completed that week and allocate unaccounted time proportionally.
The deliverable method
List everything you shipped or moved forward during the week. Pull requests merged, tickets closed, documents written, reviews completed. Estimate how long each deliverable took. Subtract the time already captured by git and calendar. Distribute the remainder.
The subtraction method
Start with your total working hours for the week — say 40. Subtract every meeting from your calendar. Subtract every coding session from your git log. The residual time is your estimation target. Assign it to the tasks that required effort but left no digital trace: thinking, planning, pair programming on someone else’s machine, whiteboard sessions.
Stay honest
Estimation is not fabrication. Round to the nearest 15 minutes, not the nearest hour. If you genuinely cannot account for 90 minutes on Wednesday afternoon, record it as general project work or admin time. Do not pad. Managers and finance teams spot patterns in inflated timesheets faster than you think.
For more on mapping development activity to billable time accurately, see mapping git commits to billable time.
How Do You Prevent This from Happening Again?
Reconstructing a timesheet once is a rescue operation. Doing it every Friday is a broken process. Here is how to fix the root cause.
Automatic time tracking
The most reliable fix removes the human from the loop entirely. Automatic tracking tools monitor your development activity — commits, branch switches, file saves — and build your timesheet in the background. You review and submit rather than recall and type.
This approach works particularly well for developers. The data sources (git, IDE, calendar) are structured and machine-readable. An automatic tracker that monitors these signals captures 90%+ of your working time without you touching a button. And it does so without screen recording or keystroke logging — see tracking productivity without surveillance for why that distinction matters.
Daily micro-reminders
If automatic tracking is not available, set a daily reminder. Not at 5 pm — by then you have already forgotten the morning. Set two:
- 11:30 am: Log what you did this morning
- 4:30 pm: Log what you did this afternoon
Each entry takes 60 seconds when the work is fresh. That is two minutes a day versus 30 minutes of Friday panic.
Weekly micro-review
Every Friday at 2 pm, spend five minutes reviewing your timesheet for the week. Cross-check against your git log and calendar. Fill any gaps while they are still within reach of your short-term memory. This single habit eliminates 95% of timesheet emergencies.
Make it part of your workflow
The developers who never forget to track time are the ones who built it into their existing routine. They log time when they close a pull request. They update their timesheet when they finish a standup. They treat it as the final step in any task, not a separate chore they will “get to later”.
Key Takeaway: Reconstruct missed timesheets from git logs, calendar, and browser history. Then set up automatic tracking or daily reminders so you never have to do it again.
Frequently Asked Questions
How accurate is a timesheet reconstructed from git logs?
Git-based reconstruction typically captures 70-85% of a developer’s real working time. It is strong on coding sessions but misses meetings, research, debugging without commits, and communication. Cross-referencing with calendar and Slack data pushes accuracy above 90%.
Can I get in trouble for submitting a reconstructed timesheet?
It depends on your organisation’s policy. Most companies prefer a good-faith reconstruction over a blank timesheet. Be transparent — tell your manager you are reconstructing from digital records rather than memory. The resulting timesheet is usually more accurate than one filled in from recall anyway.
How long does it take to reconstruct a full week?
With the methods in this guide, about 20-30 minutes. Git log extraction takes two minutes. Calendar export takes another two. The rest is cross-referencing and filling gaps. The first time is slower as you learn the commands; subsequent reconstructions go faster.
What if I work across multiple clients and need project-level accuracy?
Use branch naming conventions and repository names to attribute git commits to specific projects. Calendar events usually reference client names in the title. Combine both data sources to build per-project breakdowns. The subtraction method handles any remaining unattributed time.
Is automatic time tracking better than manual tracking?
For developers, yes. Automatic tracking captures work from structured data sources — git, IDE activity, calendar — without requiring manual input. It eliminates the recall problem entirely. The key requirement is that the tool reconstructs time from work signals rather than surveillance methods like screenshots or keystroke logging.