Work Log
A GitHub-style contribution heatmap showing what each developer actually worked on — commits, PRs, reviews, and issue completions — broken down by work category.
The Work Log (/work-log) gives engineering managers a visual account of what their team is actually working on each day — not estimates or self-reports, but activity data pulled directly from GitHub, Jira, and Linear.
Think of it as a GitHub contribution graph, but category-aware: each cell in the heatmap represents a day of activity, colored by intensity, with a breakdown of what type of work drove that activity.
What the Work Log shows
Contribution heatmap
A 90-day heatmap grid (one row per developer, one column per day) where cell color indicates activity intensity:
- Empty — no recorded activity
- Light — 1–3 events (commits, PR opens, reviews, issue completions)
- Medium — 4–8 events
- Dark — 9+ events
Click any cell to see the individual events that day: which PRs were opened, which issues were resolved, which reviews were left.
Category breakdown bar
Below the heatmap, a horizontal bar chart shows each developer's work distribution across categories over the selected period:
| Category | What's included |
|---|---|
| Feature development | PRs linked to feature issues / epics |
| Bug fixes | PRs or issues tagged as bug / defect |
| Code review | PR reviews submitted |
| Maintenance | Dependency updates, chores, refactors |
| Incident response | Activity during active PagerDuty / Opsgenie incidents |
| Other | Unlinked commits, unclassified activity |
Categories are derived from issue labels, PR titles, and linked Jira/Linear issue types. The Other row surfaces unlinked work — commits or PRs not connected to any issue, which often represents invisible toil.
Date range and filters
- Date range: 7 days / 14 days / 30 days / 90 days (default 30 days)
- Team filter: Scope the heatmap to a specific team
- Developer filter: Pin one or more developers for focused analysis
Healthy vs. unhealthy patterns
| Pattern | What it signals |
|---|---|
| Consistent medium-density cells | Sustainable pace |
| Spiky activity (dark cells clustered around releases) | Crunch cycles — may indicate poor sprint planning |
| Long gaps in individual rows | PTO, blocked work, or invisible work not captured by integrations |
| High "Incident response" share | On-call burden is eating into feature capacity |
| High "Other / unlinked" share | Work isn't being tracked — epics/issues not linked to PRs |
Data sources
The Work Log aggregates events from:
- GitHub — commits, PR opens, PR merges, review submissions, review comments
- Jira — issue status transitions (In Progress → Done), comments
- Linear — issue completions, cycle completions
Activity is attributed to the developer who authored the commit or created the event, matched by GitHub login and email.
Privacy and visibility
- Work Log respects your org's visibility setting (configured at Settings → Visibility)
- In Role-Based Access mode, managers see their direct team; members see only their own row
- In Full Transparency mode, all rows are visible to all dashboard users
- No code content is ever shown — only event counts and categories
Related docs
Daily Standup Digest
Auto-generate a pre-standup briefing for your team — surfaces blockers, at-risk PRs, and each developer's current focus.
Developer Surveys
Create and distribute developer experience surveys to measure team satisfaction, tooling effectiveness, collaboration quality, and NPS over time.