Pull requests contain enough timestamped activity to reconstruct developer time automatically. By analysing commit intervals, review events, and merge timestamps, tools can generate accurate timesheets with zero manual input from the developer.
Developers spend hours on pull requests — writing code, iterating on feedback, reviewing colleagues’ work — yet none of this activity appears in a traditional time tracking tool unless someone remembers to start a timer. That gap between what git records and what the billing system sees is where hours disappear. The good news is that the data needed to close that gap already exists inside every PR. The signals are precise, timestamped, and machine-readable. What changes is who interprets them.
Why do developers stop tracking time manually?
Manual time tracking assumes developers can context-switch into an administrative task every time they shift focus. They cannot. A developer context-switches roughly 13 times per hour across code, Slack, code review, and documentation. Asking them to log each switch is asking them to make their slowest tool the centre of their workflow.
Adoption statistics reflect this. Most teams see manual time tracking compliance drop below 60% within three months of rollout. The hours that do get logged are reconstructed at the end of the day or the end of the week — which means they are approximations at best, and plausible fiction at worst.
The billing cost of rounded hours
When developers reconstruct time from memory, they round. Half-days become four hours. Three-hour stretches become half-days. The rounding introduces a consistent undercount that compounds across a team. A five-person team rounding to the nearest hour loses an average of 20% of billable output per week, according to tracking data from professional services firms. Passive tracking from PR activity eliminates the rounding problem because the data was never approximated in the first place.
What signals do pull requests contain for time tracking?
A pull request is a structured event log. Every meaningful action — creating the branch, pushing a commit, requesting a review, receiving comments, pushing revisions, and merging — carries a UTC timestamp. That log is the raw material for a time reconstruction.
The specific signals and what they represent:
- First commit timestamp to PR open — initial coding time before the work was ready for review
- PR open to first review request — polish and self-review period
- Review request to review completion — reviewer’s active engagement time
- Review completion to revision commits — time spent addressing feedback
- Revision commits to merge — final approval and merge pipeline
- CI/CD pipeline durations — build and test wait time that the developer monitors
Each of these intervals is observable without any developer action. The timestamps exist in the git and pull request APIs regardless of whether anyone is tracking them.
Commit frequency as a session signal
Beyond the PR-level intervals, the gaps between individual commits carry their own signal. This is the same principle behind mapping git commits to billable time, applied at the PR level. A series of commits spaced two to eight minutes apart indicates active coding. A gap of ninety minutes or more suggests a break, a meeting, or a context switch to a different task. Session detection algorithms use these gap patterns to segment continuous work periods from idle time.
The threshold that separates “still in session” from “new session” is typically configurable. A 30-minute default works well for most teams. Adjust it downward for developers who commit very frequently, upward for those who work in longer, deeper focus blocks.
How does automatic PR time tracking work technically?
The six-step pipeline that converts raw PR activity into a reviewable timesheet:
Step 1: Connect to your git provider. The tracking tool authenticates via OAuth or a webhook configuration. This grants read access to PR events, commits, and review data. No write access to your repository is needed.
Step 2: Ingest PR events. The tool streams or polls events from the git provider API — PR opened, commit pushed, review requested, review submitted, comment posted, merge completed. Each event arrives with a timestamp and an actor.
Step 3: Apply session detection. A gap analysis algorithm walks the commit timeline and groups consecutive commits into sessions. Commits within 30 minutes of each other (by default) are treated as a single continuous work period. Gaps beyond the threshold start a new session.
Step 4: Correlate with calendar data. Meetings do not appear in git. An engineering manager’s calendar might show a two-hour planning session on Tuesday afternoon — which explains why git shows no commits in that window. Pulling in calendar events fills those gaps with correctly labelled meeting time rather than leaving them as unexplained voids.
Step 5: Map PRs to projects and clients. Branch naming conventions, repository labels, or ticket references in commit messages provide the mapping. A branch named proj/client-acme/feature-login maps to the ACME client automatically. Teams that do not yet have naming conventions can configure explicit mapping rules. If your team spans several codebases, the same approach scales — see how to track time across multiple git repos for configuration patterns.
Step 6: Generate and surface time entries. The reconstructed sessions become draft time entries. The developer reviews them — a two-minute task rather than a twenty-minute one — corrects anything the algorithm misread, and approves. The approved entries flow into the invoicing or project management stack.
How accurate is PR-based time tracking?
PR-based tracking consistently captures 70–85% of active developer time when used alone. The figure climbs to 90%+ when calendar data is added to cover meetings, pair-programming sessions, and planning time that leaves no git trace.
What PR tracking captures well
Code writing, test authoring, refactoring, and code review are all well-captured because they produce git events. The timestamps are machine-generated and accurate to the second. There is no human memory involved and no opportunity for rounding.
What PR tracking misses
Offline research — reading documentation, thinking through an architecture decision, or sketching a design — leaves no git trace. Neither does a Slack thread that resolves a blocking question before a developer writes a single line of code. These represent approximately 15–30% of senior developer time.
Why 85% passive beats 60% manual
A team that manually logs time achieves approximately 60% compliance in steady state. The 40% that goes unlogged is effectively invisible. Passive PR tracking captures 85% without any developer effort. Even before adding calendar integration, the passive approach captures more total working time than a well-run manual tracking programme.
How do I set up PR time tracking for my team?
Five steps to go from zero to automatic time entries:
- Choose a tool that integrates with your git provider. Confirm it supports your version control host — whether that is a cloud-hosted service or a self-managed instance — and that it can handle private repositories.
- Configure project and client mapping rules. Define the branch naming conventions, repository labels, or ticket reference patterns that identify which client or project a PR belongs to.
- Set your session timeout threshold. Start with 30 minutes. Review the first week of generated entries to see whether sessions are being split where they should not be, and adjust accordingly.
- Establish a lightweight review process. Schedule a five-minute end-of-day review for developers to approve or adjust generated entries. This catches the edge cases the algorithm misses and keeps the audit trail clean.
- Connect to your invoicing or project management stack. Approved entries should flow automatically into wherever your billing team generates invoices. Manual export and import reintroduces the friction you are trying to eliminate.
Keito tracks developer time automatically from git and pull requests. Zero manual entry. Try it free.
Key Takeaway
Pull requests contain rich timestamped signals that reconstruct developer time automatically. Combined with calendar data, PR-based tracking covers 90%+ of developer hours without manual input.
Frequently Asked Questions
How accurate is time tracking based on pull requests?
PR-based time tracking typically captures 70–85% of active developer time on its own. When combined with calendar integration to cover meetings and offline work, accuracy reaches 90% or more. This consistently outperforms manual tracking, which averages around 60% compliance in practice.
Does PR-based time tracking work with private repositories?
Yes. Tools that use OAuth authentication or webhook-based event streaming can access private repositories with appropriate permissions. The tracking tool needs read access to pull request events, commits, and review data — no write access is required.
Can I track time from PRs across multiple repositories?
Yes. Most PR time tracking tools support multi-repository configurations. You can set up mapping rules that assign commits and PRs from different repositories to the corresponding project or client, then aggregate the time entries into a single timesheet.
Does this capture code review time as well as coding time?
Yes. Review request timestamps and review submission timestamps are both part of the PR event log. The time between a review request and a completed review is attributed to the reviewer. Comment threads and subsequent revision commits capture the rework cycle on the author’s side.
What happens if a developer works on multiple PRs simultaneously?
Session detection algorithms handle overlapping PRs by attributing time to the repository and branch that was most recently active. When commits to two different PRs are interleaved closely in time, some tools split the session proportionally. Others flag the overlap for manual review. Check how your chosen tool handles concurrent PR work before rolling out to a team that does heavy parallelisation.