If your team uses GitHub (and let's face it, you probably do if you have developers in your team), you might be wondering: can't I just track time where my team actually work?
The short answer: not out of the box.
But the good news? You've got options that won't destroy your flow. Plus, it's not necessary to switch out of GitHub to something that has native time tracking.
GitHub Issues: More Than Just Bug Reports
GitHub Issues gets a bad rap as "just a bug tracker," but that's selling it short.
Maybe once upon a time, GitHub Issues was something simple. But the product has evolved far beyond that and can now compete with many dedicated PM tools.
Moreover, developers love it and understand it intuitively. From a team perspective, it's better to do everything in one place.
Every issue connects directly to your code. Close an issue by writing "Fixes #42" in your commit message, and GitHub automatically links everything together. Six months later, when someone asks "why did we implement it this way?", the entire discussion is right there.
Real scenario: Stakeholder creates an issue: "Users can't upload files over 10MB." You dig into it, discover it's a config problem, fix it in a PR that references the issue, and the whole story - problem, investigation, solution - is documented without you thinking about it. Future you will thank present you.
GitHub Projects: Your Work, Visualized
Moreover, GitHub Projects gives you Kanban boards, tables, and timeline views that actually sync with your issues and PRs.
Here's what makes it different from standalone project tools: everything stays connected. Drag an issue from "To Do" to "In Progress" and everyone sees it. Close a PR and watch the related card automatically move to "Done." Your board isn't a static snapshot - it's a live view of what's actually happening.
You can add custom fields like priority, complexity, or target dates. Filter views to show just your team's current sprint. Use automation to move cards when issues get labeled or assigned. And yes, you can create "draft issues" for those half-baked 2am ideas that aren't ready for prime time yet.
GitHub Issues supports all of those "normal" project management features, and in some cases, integrates them more tightly with the developer workflow than standard PM tools:
Attach Files and Images: You can easily attach files and images by dragging and dropping them into the comment or description box. GitHub hosts the file and embeds a link or image preview directly in the issue.
Checklists/Tasklists: GitHub uses Markdown tasklists to create interactive checklists within the issue description or comments. The progress (e.g., "4 of 6 tasks complete") is often summarized in the main issue list view
Subtasks and Dependencies: GitHub handles subtasks through the use of tasklists (for simple checklists) or by linking multiple issues together as dependent tasks. The Projects tool allows you to visualize these dependencies and hierarchies effectively.
Videos: Videos can be attached as files (subject to size limits) or embedded via links to hosting services in the markdown description or comments.
Formatting: GitHub uses GitHub Flavored Markdown (GFM), which provides extensive formatting options including bold, italics, headers, code blocks with syntax highlighting, tables, bullet points, numbered lists, blockquotes, strikethrough, and horizontal rules.
GitHub shows completion percentage automatically. It's perfect for breaking down bigger features without drowning in tiny issues.
These features allow GitHub issues to serve as rich, well-documented tasks that keep all relevant information - from initial discussions to attached debug logs and code references - in one centralized location.
Sample GitHub Issue Template
Below is a detailed GitHub issue example that you can copy and paste as a demo. It showcases all the formatting options we discussed - including tables, code blocks, checklists, collapsible sections, videos, and more.
## 🐛 Bug Report: File Upload Fails for Files Over 10MB
### Description
Users are unable to upload files larger than 10MB through the web interface. The upload progress bar reaches 100% but then shows an error message.
### Steps to Reproduce
1. Navigate to `/upload` page
2. Select a file larger than 10MB (tested with 15MB PDF)
3. Click "Upload" button
4. Wait for progress bar to complete
5. Error appears: "Upload failed - please try again"
### Expected Behavior
Files up to 50MB should upload successfully based on our documentation.
### Actual Behavior
Upload fails silently after progress completes. No error logged in browser console initially, but network tab shows `413 Payload Too Large` response.
### Environment
- **Browser**: Chrome 120.0.6099.109
- **OS**: macOS 14.1
- **Server**: Production (api.example.com)
- **User Role**: Premium subscriber
### Screenshots & Media
**Error Message:**
**Network Tab showing 413 error:**
**Video Demonstration:**
https://github.com/user-attachments/assets/sample-video-uuid.mp4
> **Note:** Video shows the complete upload flow: selecting file → progress bar → error message. Notice how the progress bar completes but then fails.
**Alternative video hosting:**
You can also embed videos from YouTube or other platforms:
[](https://www.youtube.com/watch?v=dQw4w9WgXcQ)
**GIF showing the issue:**
### Technical Details
<details>
<summary>Click to expand: Request/Response Details</summary>
**Request Headers:**
```http
POST /api/v2/upload HTTP/1.1
Host: api.example.com
Content-Type: multipart/form-data
Content-Length: 15728640
```
**Response:**
```json
{
"error": "payload_too_large",
"message": "Request entity too large",
"max_size": 10485760,
"received_size": 15728640
}
```
**Full Request Payload:**
```javascript
{
"file": {
"name": "large-document.pdf",
"size": 15728640,
"type": "application/pdf",
"lastModified": 1702899234567
},
"metadata": {
"userId": "usr_12345",
"uploadedAt": "2024-12-18T10:30:45Z",
"category": "documents"
}
}
```
</details>
<details>
<summary>Click to expand: Server Logs</summary>
```log
2024-12-18 10:30:47 [ERROR] nginx: client intended to send too large body
2024-12-18 10:30:47 [INFO] Request ID: req_abc123xyz
2024-12-18 10:30:47 [ERROR] 413 Payload Too Large - /api/v2/upload
2024-12-18 10:30:47 [INFO] Client IP: 192.168.1.100
2024-12-18 10:30:47 [INFO] User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X)
```
</details>
<details>
<summary>Click to expand: Configuration Files</summary>
**Current nginx.conf (INCORRECT):**
```nginx
server {
listen 80;
server_name api.example.com;
# Problem is here!
client_max_body_size 10M;
location /api/ {
proxy_pass http://backend:3000;
proxy_set_header Host $host;
}
}
```
**Proposed nginx.conf (CORRECT):**
```nginx
server {
listen 80;
server_name api.example.com;
# Fixed to match application limits
client_max_body_size 50M;
location /api/ {
proxy_pass http://backend:3000;
proxy_set_header Host $host;
proxy_request_buffering off; # Better for large uploads
}
}
```
</details>
### Root Cause Analysis
<details>
<summary>🔍 Click to expand: Detailed Investigation Timeline</summary>
**December 15, 2024 - Deployment Day**
- 09:00 AM: Infrastructure update deployed to production
- 09:15 AM: First upload failures reported
- 10:30 AM: Support tickets start increasing
- 11:00 AM: Investigation begins
**Investigation Steps:**
1. ✅ Checked application logs - no errors
2. ✅ Reviewed recent code changes - no upload-related changes
3. ✅ Tested API directly with curl - reproduced issue
4. ✅ Compared staging vs production configs
5. ✅ **Found discrepancy in nginx config**
**Configuration Drift:**
```diff
# Staging (working)
- client_max_body_size 50M;
# Production (broken)
+ client_max_body_size 10M;
```
**Why it happened:**
The December 15th deployment used an outdated nginx template that didn't include the November increase from 10M to 50M.
</details>
<details>
<summary>📊 Click to expand: Historical Data & Trends</summary>
**Upload Size Distribution (Last 30 Days):**
- 0-5MB: 15,234 uploads (85%)
- 5-10MB: 1,891 uploads (10%)
- 10-25MB: 678 uploads (4%)
- 25-50MB: 197 uploads (1%)
**Error Rate Over Time:**
```
Dec 01-14: 0.2% failure rate (baseline)
Dec 15: 12.5% failure rate ⚠️
Dec 16: 15.3% failure rate ⚠️
Dec 17: 18.7% failure rate ⚠️
Dec 18: 21.4% failure rate 🔴
```
**User Impact by Subscription Tier:**
| Tier | Affected | Total | Percentage |
|------|----------|-------|------------|
| Free | 234 | 50,000 | 0.5% |
| Basic | 412 | 8,000 | 5.2% |
| Premium | 1,654 | 5,000 | 33.1% 🔴 |
</details>
### Proposed Solution
**Option 1: Quick Fix (Recommended)**
Update nginx configuration:
- [ ] Update `client_max_body_size` to 50M in nginx.conf
- [ ] Update application validation to match (currently allows 50M)
- [ ] Deploy to staging for testing
- [ ] Deploy to production
**Option 2: Long-term Solution**
Implement chunked uploads for better UX:
- [ ] Design chunked upload API endpoint
- [ ] Implement client-side chunking (5MB chunks)
- [ ] Add resume capability for failed uploads
- [ ] Update documentation
### Impact Assessment
| Metric | Value | Status |
|--------|-------|--------|
| Severity | High | 🔴 Critical |
| Affected Users | ~2,300 (last 30 days) | 📈 Growing |
| Support Tickets | 47 (last week) | ⚠️ High volume |
| Revenue Impact | $12,000/month | 💰 Premium feature |
| Average Resolution Time | 4.5 hours | ✅ Acceptable |
### Browser Compatibility Testing
| Browser | Version | Upload 5MB | Upload 15MB | Upload 50MB | Notes |
|---------|---------|------------|-------------|-------------|-------|
| Chrome | 120.x | ✅ Pass | ❌ Fail | ❌ Fail | 413 error |
| Firefox | 121.x | ✅ Pass | ❌ Fail | ❌ Fail | 413 error |
| Safari | 17.x | ✅ Pass | ❌ Fail | ❌ Fail | 413 error |
| Edge | 120.x | ✅ Pass | ❌ Fail | ❌ Fail | 413 error |
### Related Issues
- Relates to #892 (Large file upload documentation)
- Blocks #1204 (Video upload feature)
- Similar to #756 (resolved - but config reverted during last deploy)
### Checklist
- [x] Bug confirmed and reproducible
- [x] Root cause identified
- [x] Solution proposed
- [ ] Approval from DevOps team
- [ ] Fix implemented
- [ ] Tests written
- [ ] Documentation updated
- [ ] QA verified on staging
- [ ] Deployed to production
### Additional Context
This was working correctly until the December 15th deployment. The nginx config was likely overwritten during the infrastructure update. We should add this to our deployment checklist.
**Priority**: 🔴 Critical
**Labels**: `bug`, `infrastructure`, `production`, `user-impacting`
**Milestone**: Sprint 23
**Assignees**: @devops-team @backend-team
---
### Comments Summary
**@alice** (DevOps Lead) - *2 hours ago*
> Confirmed the nginx config issue. I can deploy the fix within 30 minutes. Will coordinate with @bob for application-side validation check.
**@bob** (Backend Dev) - *1 hour ago*
> Application code looks good - already configured for 50MB. Just need the nginx update. I'll monitor error rates after deployment.
**@charlie** (Product Manager) - *45 minutes ago*
> Thanks for the quick turnaround! Let's also add this to our post-deployment verification checklist so it doesn't happen again.
---
**Time Tracking** ⏱️
- Investigation: 2h 30m
- Fix implementation: 45m
- Testing: 1h 15m
- **Total**: 4h 30m
> **Note:** This issue demonstrates GitHub's rich formatting capabilities including tables, code blocks, checklists, mentions, images, and structured content that keeps everything in one place.
The Time Tracking Gap (And How to Fill It)
Here's where GitHub has a blind spot: time tracking. There's no built-in timer and no estimates. No way to see "Developer X spent 4.5 hours on issue #127."
Why does this matter? Because at some point, someone needs to know:
- How long features actually take (for better estimates)
- Where the team's time is going (capacity planning)
- What to bill clients (if you're an agency)
- Whether that "quick fix" was actually quick
You've got three approaches:
1. Use a Dedicated Integration (The Smart Choice)
Tools like Everhour add all necessary time tracking controls directly inside GitHub. Install a browser extension, and suddenly every issue and PR has time, shows estimates, progress, budget. Your time logs live right alongside your code discussions.
Why this works: Zero context switching. You're already in GitHub reviewing code or updating an issue - now you just click one extra button. The tool handles the math, generates reports, and can even calculate costs or create invoices.
Everhour is particularly solid for teams that need budgets and approvals. Toggl Track or Harvest is more like start/stop buttons. But you can pick based on what pain point you're actually solving.
2. Manual Time Logs (The DIY Route)
No budget? No problem. Just comment on issues with a consistent format:
⏱️ 2h - Investigated root cause, turns out it was a race condition
⏱️ 45m - Code review on PR #234
Pros: Free, simple, requires no setup.
Cons: Requires discipline. You'll forget. Everyone forgets. It doesn't make sense to commit just to record time. And without it your data won't be accurate.
3. GitHub Actions Automation
If you're comfortable with workflows, you can use GitHub Actions to log timestamps when issues move between columns or when PRs are opened/merged. This gives you cycle time data ("how long do issues spend in each stage?") rather than actual work time.
This is useful for process optimization - finding bottlenecks in your workflow - but it won't tell you how many hours a developer actually spent coding. It's more about flow than effort.
How to Choose Your Time Tracker
Here's a review of top apps that usually pop up when you search for a GitHub time tracker.
Everhour
Ideal for teams who need more than just time tracking
- Free trial
- $10/user monthly or $8.5 when billed annually
Start by creating an Everhour account and connecting your GitHub. Sync is automatic, after which you can invite team members. You don't need to invite everyone - only those who actually track time.
Everhour includes many useful features beyond basic time tracking. You can explore them in detail on the GitHub integration page. With Everhour, your team can track time not only in GitHub but also across multiple tools, such as ClickUp, Notion, or Asana, and aggregate all time data in one place.
The browser extension must be installed by each user. Extensions also don't work in GitHub's native mobile apps, which may be a limitation for teams that work on the go.
Pros / Cons:
- Simple setup with automatic sync
- Auto-updates data if issues are renamed in GitHub
- Works in many areas of the GitHub interface
- Cross-platform tracking (GitHub + other tools)
- Comprehensive features: budgets, invoicing, reporting
- Requires browser extension installation
- Doesn't work inside GitHub native mobile apps
- Some companies restrict extensions for security reasons
Toggl Track
Best for simplicity and lightweight tracking
- Free for up to 5 users
- Paid plans from $10/user/month
Toggl Track adds a one-click timer directly inside GitHub through its browser extension. The interface is clean and intuitive, making it ideal for individuals or small teams who want straightforward time tracking without complexity.
The tool excels at simplicity but lacks advanced features like budgeting, approval workflows, or deep integrations with project management tools. If you need more than start/stop timers and basic reports, you may outgrow it quickly.
Pros / Cons:
- Very simple and intuitive interface
- One-click start/stop timers
- Free plan for small teams (up to 5 users)
- Good for trust-based environments
- Limited advanced features (no budgets or approvals)
- Basic reporting compared to alternatives
- Requires browser extension installation
Harvest
Best for agencies focused on client billing
- Free plan for 1 user, 2 projects
- Paid plan: $12/user/month
Harvest integrates with GitHub through a browser extension and is designed specifically for agencies and consultants who bill clients by the hour. It excels at connecting time tracking to invoicing and accounting workflows.
The GitHub integration is relatively basic - it's more about capturing time than managing projects. If your team already uses Harvest for billing and just needs to add GitHub time tracking, it's a natural fit. But if GitHub is central to your workflow, more dedicated tools offer deeper integration.
Pros / Cons:
- Strong invoicing and billing features
- Integrates with QuickBooks, Xero
- Simple visual interface
- Good for client-facing work
- Basic GitHub integration depth
- More expensive than alternatives
- Limited project management features
Hubstaff
Best for compliance and detailed activity monitoring
- Free for 1 user
- Paid plans from $7/user/month
Hubstaff is designed for distributed teams that need more visibility into how time is spent. It includes optional screenshots, activity monitoring, GPS tracking, and productivity metrics - features that can feel invasive if not implemented thoughtfully.
The GitHub integration allows time tracking on issues and pull requests, but the tool's strength is in workforce management rather than developer workflow optimization. Use it only if you have a legitimate compliance need or manage remote teams where transparency is required.
Pros / Cons:
- Detailed activity tracking and screenshots
- GPS and location tracking for remote teams
- Payroll and invoicing features
- Good for compliance-heavy industries
- Can feel invasive to team members
- More focused on monitoring than collaboration
- May harm trust-based team culture
Making It Actually Work
The best time tracker is the one everyone actually uses. Here's how to increase adoption:
Keep it optional at first. Let early adopters prove value before mandating it.
Start with one project. Don't roll it out company-wide on day one.
Review the data together. Show the team how time data helps them - better estimates, clearing blockers, proving you need more resources.
Don't weaponize it. The moment time tracking becomes a productivity witch-hunt, you've lost. Use it for planning and improvement, not punishment.
The Bottom Line
GitHub already handles your code, issues, PRs, CI/CD, and project management. It's 95% of what you need. The missing 5% - time tracking - isn't hard to add with the right tool.
The goal isn't surveillance or micromanagement. It's answering simple questions: Where does our time actually go? Are we getting faster or slower? What should we focus on next?
When you track time where you work - not in some separate system you have to remember to update - it stops feeling like homework and starts feeling like useful data.
Pick a tool that fits your workflow, try it for a sprint, and see if it helps. Worst case? You learn something about your team's actual capacity. Best case? You finally have real data to push back when someone says "this should only take a few hours."
Ready to try time tracking in GitHub? Most tools offer free trials. Start with the simplest option that solves your actual problem - not the one with the longest feature list.
