To set up time tracking with GitHub, pick one of three routes: add time: labels to issues, install a time-tracking GitHub App that reacts to slash commands, or connect an activity-based tool that builds timesheets automatically from your commits, PRs, and reviews.
You close 14 pull requests in a week, ship a critical hotfix at midnight, and spend half of Friday in code reviews — yet your timesheet shows blank rows because nobody remembered to log anything. That gap between the work GitHub records and the hours your billing system sees is the single biggest cause of revenue leakage for engineering teams. This guide walks through the three practical approaches, the setup steps for each, and how to pick one that survives past your first sprint.
Why is GitHub alone not enough for time tracking?
GitHub is excellent at recording what happened. A commit has a timestamp. A pull request has an opened date, a merged date, and a trail of reviews. An issue has a lifecycle from open to closed.
What GitHub does not record is how long any of that took. A commit timestamp tells you when code was pushed, not when the developer started thinking about the problem. A pull request merged at 10am might represent 20 minutes of work or three days of iteration. Without explicit time data, billing teams and project managers are guessing.
The hidden cost is context switching. A 2017 University of California study found it takes an average of 23 minutes to refocus after an interruption. Forcing developers to flip between an editor, a PR review, and a separate timer is itself a productivity tax. Inaccurate timesheets then show up downstream as under-billed hours, mis-scoped sprints, and frustrated engineers who feel their effort is invisible.
Approach 1: Can you track time with GitHub labels and comments?
Yes, and for small teams it can be the fastest place to start. The pattern is simple. You create a fixed set of labels — time: 15m, time: 30m, time: 1h, time: 2h, time: 4h, time: 1d — and apply them to issues or pull requests as work progresses.
How do you automate the totals?
A GitHub Actions workflow can tally label values and post a weekly summary to an issue or a project board. A minimal workflow listens to issues.closed events, reads the time: labels, parses the suffix, and writes totals to a JSON artefact or an external store.
on:
issues:
types: [closed]
schedule:
- cron: '0 17 * * 5'
jobs:
tally:
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v7
with:
script: |
const labels = context.payload.issue.labels
.filter(l => l.name.startsWith('time:'));
// parse and sum, then post to summary issueThe upside is zero extra tooling. The downside is it relies on developers remembering to apply the right label at the right time. In our experience, label discipline holds for the first two weeks of a new process and then quietly slips.
When does label-based tracking break?
Once you cross roughly ten active contributors. Audit loads increase, labels drift (time:1h, time: 1h, time_1h all appear), and nobody wants to own the cleanup. It also cannot capture code review time — the label sits on the PR, but the reviewer’s hours are invisible.
Approach 2: How do you set up a GitHub App for time logging?
A GitHub App or bot listens to webhook events and exposes slash commands inside issues and PRs. A developer types /time 45m investigating auth bug and the bot stores the entry against the issue, the repo, and the author.
What permissions does the GitHub App need?
A time-tracking GitHub App typically needs read access to issues, pull requests, and repository metadata, plus write access to issue comments so it can confirm logged entries. Request only what you need. Over-scoped apps are a red flag during security reviews and a common blocker for enterprise rollouts.
Step-by-step:
- Register a new GitHub App in your organisation settings, set the homepage URL, and generate a private key.
- Subscribe to
issues,issue_comment,pull_request, andpull_request_reviewwebhook events. - Point the webhook URL at your receiver — a serverless function or a small Node service behind an HTTPS endpoint.
- Install the App on the repositories you want to track and test with a sample
/timecommand. - Verify entries appear in your external dashboard and flow back into your billing tool.
What are the real limits of bot-based tracking?
Bots are better than labels but still require active logging. Developers must remember to type the command during or right after the work, and anything done outside GitHub — a kick-off call, whiteboarding, pair programming on a separate machine — never reaches the bot. A 2024 developer experience report from Stack Overflow noted that over 60% of developers work across three or more tools daily, which makes any single-tool capture method fundamentally incomplete.
Approach 3: How does automated time tracking from git activity work?
Activity-based tools reconstruct timesheets by watching what actually happens across your git workflow. Instead of asking the developer to log, they observe commits, branch switches, pull request openings, review comments, and merge events — then group that activity into time blocks using heuristics about gaps, project context, and repository-to-client mapping.
The practical outcome is a draft timesheet that appears on Friday afternoon with entries already filled in. The developer reviews it, nudges a couple of entries, and approves. That is very different from starting with a blank timesheet and trying to remember what Tuesday looked like.
What does the setup look like end to end?
- Connect the GitHub organisation via OAuth. The integration requests read-only access to repos, PRs, reviews, and commit metadata. No code contents need to leave the system.
- Map repositories to projects or clients. A single repo can belong to one client; a monorepo can map to several projects using path-based rules.
- Let the system observe for 48 hours. The first draft timesheet benefits from a short baseline of activity.
- Review the auto-generated entries. Each entry shows the source events — the commits, PRs, or reviews that produced it — so the developer can verify without trust falls.
- Approve and export. Approved hours sync to invoicing or project management tools so nothing is re-keyed.
This is the same principle behind mapping git commits to billable time, extended to cover the full GitHub event surface rather than commits alone. For teams that also need to capture review effort specifically, pair this with a dedicated look at tracking time spent on code reviews.
Does it count code review time?
Yes, provided the tool listens to pull_request_review and pull_request_review_comment events. These webhooks fire every time a reviewer comments, approves, or requests changes. Tools that only parse commit logs cannot see review work — an important question to ask during any procurement.
What about work done outside GitHub?
The honest answer: no git-activity tool can see what you did in your editor before you committed, or the meeting that preceded the ticket. Mature integrations pair GitHub activity with calendar events and editor telemetry to close that gap. If your team lives mostly inside VS Code, adding an editor plugin alongside the GitHub integration gives close to full coverage.
How do you pick the right approach for your team size?
| Team size | Recommended approach | Why |
|---|---|---|
| 1-5 developers | Labels + weekly Actions summary | Zero cost, low overhead, discipline is manageable |
| 5-15 developers | GitHub App with slash commands | Structured logging, lightweight governance |
| 15+ developers | Activity-based automation | Manual logging breaks at scale; you need observation, not memory |
| Agencies billing multiple clients | Activity-based with repo-to-client mapping | Audit trail matters for disputes |
There is a reasonable middle path: start with labels while you prove a process works, then graduate to an activity-based tool once the volume makes manual logging unsustainable. What you do not want is three parallel systems — that way lies the reconciliation spreadsheet of doom.
What should you do after the integration is live?
Three things, in order. First, agree a review cadence — Friday afternoon works well because the week is fresh and payroll deadlines are Monday. Second, wire the approved hours into your invoicing tool so nothing is copy-pasted. Third, run a monthly audit comparing tracked hours against actual output, not to police individuals but to spot patterns — the team that under-logs is usually the team heading for burnout.
Key Takeaway: Activity-based GitHub time tracking gives the highest accuracy with the lowest developer friction. Labels and bots work for small teams but break past 10 contributors.
Frequently Asked Questions
Can I track time on private GitHub repositories?
Yes. Both bot-based and activity-based integrations work with private repos once you grant the correct OAuth scopes or GitHub App permissions. The integration only needs read access to metadata — issues, PRs, commits, reviews — not code contents.
Does time tracking from git commits count code review time?
It depends on the tool. Activity-based trackers that subscribe to pull_request_review and pull_request_review_comment webhook events can capture review time accurately. Commit-only parsers miss review work entirely, which is a common gap for reviewers in senior roles.
Will adding time tracking slow down my CI/CD pipeline?
No. Time tracking integrations operate on webhook events or periodic API polling and run outside your build and deploy pipeline. They do not insert steps into Actions workflows, so build duration is unaffected.
How do I handle developers who work across multiple repositories in a day?
Activity-based tools stitch events across repos into a single timeline for each developer, then split the resulting time blocks based on the repo each commit or PR belongs to. For label-based approaches, you need consistent project: labels alongside time: labels so reports can group correctly.
What is the best way to bill clients from GitHub-tracked hours?
Map each repository to a client or project in your billing tool, then export approved hours as a CSV or via API at the end of each billing cycle. For teams already using accounting software, look for a direct sync so hours flow straight into draft invoices without re-keying. See our guide on generating invoices from tracked hours for the full workflow.
Is it possible to track time across both GitHub and a separate issue tracker?
Yes, and it is common. The pattern that works is using GitHub for code activity and the issue tracker for task context, with an integration that correlates the two by branch name, PR reference, or ticket ID. This is especially useful when teams have moved to GitHub for code but retain an older tracker for product management.
Ready to stop filling in timesheets by hand?
Connect your GitHub organisation to Keito and let your actual git activity build your timesheet for you. Approve, export, invoice — done in minutes each Friday.