Why GitHub itself shows no time
If you have ever opened your own GitHub profile hoping to see hours, you already know the gap. GitHub was built to host code and collaboration, not to clock you. The contribution graph counts events, the commit history records when work landed, and the insights tab summarises volume, but none of it is a stopwatch. This section covers what GitHub exposes and why none of it is time.
Quick Answer
GitHub does not record how long you spent coding, so to track time spent coding on GitHub you have to infer it from the trail it does keep: commit timestamps, pushes, and contribution activity. The reliable way to do that is to reconstruct work sessions, grouping commits that sit close together in time and treating long quiet gaps as breaks, which gives you a believable baseline. The catch in 2026 is that this baseline is a benchmark, not an accurate clock. Commit size and timing no longer map to effort now that AI agents generate large diffs in seconds and a one-line fix can follow an hour of thinking. For a number you can trust, and stand behind as proof of what you shipped, you pair that git baseline with telemetry that observes the work as it happens. Below: the practical methods, what each one can and cannot tell you, and how to make the result accurate.
A commit carries an author timestamp, which tells you the moment a change was finalised, not how long the change took. A green square means at least one contribution happened that day, nothing about its duration. Pull request and push events are similar: precise about when, silent about how long. So every method for tracking time on GitHub is really a method for estimating time from these timestamps after the fact. That is doable and useful, but it is inference, and it is only as good as the assumption that commit timing reflects working time. In practice that assumption holds for some developers and breaks badly for others.
Method 1: track time spent coding on GitHub from commit history
The honest, no-plugin approach is to rebuild work sessions from your git log, which is the same data GitHub stores. Most developers reach for this first because it needs nothing installed. Here is the shape of it.
- Pull your commit timestamps. Locally,
git log --pretty=format:'%ci'gives every commit time in a repo; across GitHub, the events and commits APIs expose the same per-commit timestamps. - Sort them in order and look at the gaps between consecutive commits.
- Group commits into sessions. When two commits sit within a short window of each other, say under an hour, treat them as the same session. When a long gap appears, close the session.
- Estimate each session's length from its first to its last commit, then add a fixed allowance for the work before the first commit (the part git can never see).
- Sum the sessions per day, per week, or per project.
This is exactly what a sensible git-based estimator does under the hood, and it is genuinely informative if you commit little and often. You will often see your real working rhythm appear: the morning block, the after-lunch dip, the late push. As a rough picture of when you worked and roughly how much, it earns its keep. The trouble starts the moment you ask it to be precise.
Method 2: contribution graph and insights (weakest)
A lot of people try to read effort straight off the contribution graph, and it is the least reliable method of all. The graph is a density map of activity days, not a record of hours. This section is short on purpose, because the honest verdict is short.
Two days can both show a solid green square while one was twenty minutes and the other was nine hours. The graph also rewards committing often over working long, so it can make a busy, low-output day look identical to a deep, single-commit day. It is a fine motivation tool and a decent consistency tracker. As a time measure it is close to useless, and treating it as one is how people end up with numbers that feel wrong. If you want the deeper version of why the graph misleads, see why GitHub green squares do not prove the work.
Why the git baseline drifts, especially with AI
Here is the limitation worth being blunt about, because most "track time on GitHub" advice skips it. Git records output, not effort, and AI has pulled those two further apart than ever. The only signals available are when commits happened and how much changed, and in 2026 neither maps cleanly to time.
An agent like Claude Code, Cursor, or Codex can produce hundreds of lines and a huge diff in seconds, so a large commit can represent almost no elapsed time. The reverse is just as common: a single-line change can land after an hour of reading, prompting, and deciding what not to build. The thing GitHub can see, the size and timing of the diff, has come apart from the thing you want to measure, which is time spent. This is the core reason a pure commit-based estimate misjudges modern, AI-assisted work. It is measuring the artifact, and the artifact no longer correlates with the hours. So the git baseline is a strong cross-check and a useful benchmark, not an accurate clock, and any tool claiming to read your true hours from GitHub commits alone is guessing.
Method 3: add telemetry for an accurate number
If commits infer time after the fact from output, telemetry measures it while it happens, which is the only way to get it right. Telemetry means lightweight activity signals captured as you work: active editing, terminal sessions, and agentic coding runs, the heartbeat of real engagement. Because it observes the work directly, it reflects elapsed active time no matter how much or how little code resulted.
Telemetry sees the hour you spent debugging that ended in a one-line fix, and it sees that the giant AI-generated commit took two minutes. Those are precisely the cases where commit history gets fooled, and telling them apart is what makes a number trustworthy. You still keep your GitHub history in the picture as a benchmark and a record of when work landed, but the accurate measure of duration comes from watching the work, not from reading the diff afterward. In a world where code is cheap to generate, that is the difference between a guess and a measurement.
Where DevClocked fits
DevClocked exists for the case where you want coding time on GitHub that you can trust and reuse, including as proof of what you shipped and how much of it was you versus your AI agents. It treats your git history as the benchmark and telemetry as the ground truth for active time, then learns the relationship between them so the estimate calibrates to your real patterns. You get a Leverage Score and Work Blocks built on observed activity, not on commit counts anyone could pad.
Be honest about when you do not need it. If you only want a rough sense of which days you worked, the contribution graph is free and already on your profile. If you want a quick session estimate with nothing installed, the git-baseline method above will get you a ballpark, and you can connect git only to DevClocked for the same approximate picture with no per-editor plugin. The moment you want accuracy, you add the lightweight editor extension or the editor-agnostic CLI tracker (one tracker across your tools, not a plugin per editor), and the model fuses that telemetry with your history. And if your work barely touches GitHub, or you want your whole non-coding day tracked, a general tracker fits better than this. DevClocked earns its place when the work is code, you want a measured number rather than a commit-count guess, and you want that number to double as a record you can stand behind.
Common mistakes
The first mistake is counting commits as a proxy for time. A commit can be five seconds or five hours, so a commit count tells you about habits, not hours. The second is trusting the contribution graph as a workload measure when it only marks activity days. The third, and the one that bites hardest in 2026, is assuming a big diff means a long session. With AI in the loop that is often backwards. Almost always, the fix for all three is the same: stop reading effort off the artifact and measure the work directly.
Related Guides
- How to track coding time from git: the full mechanism, and why git is a benchmark rather than a clock.
- Estimate developer hours from commits: turning the session method into estimates and invoices, with caveats.
- Coding time tracker without an IDE plugin: the editor-agnostic tracker and where git-only falls short.
- Verify GitHub contributions: reading proof of work instead of trusting the graph.
- Why GitHub green squares do not prove the work: the deeper case against commit volume as a signal.
