After hours work

After hours work is one of the clearest early signals of a squad under strain, yet most engineering leaders only notice it once burnout has already set in. After hours work refers to code commits, pull request activity, or issue updates that occur outside a player's standard working hours, typically before 9 AM or after 6 PM on weekdays, or at any point on weekends. When this pattern becomes consistent across your squad, it usually points to a process problem: unrealistic sprint commitments, blocked work piling up, or deployment pressure that forces players to catch up on their own time. This page covers the definition, how to measure it, what benchmarks signal concern, and what engineering leaders can do about it.

Key takeaways

• After hours work is the percentage of a squad's Git and issue activity that occurs outside standard business hours. It matters because sustained after hours patterns correlate with reduced code quality, slower review cycles, and eventual attrition, all of which directly affect your team's delivery capacity.
• After hours work is calculated as the number of engineering events (commits, PR opens, reviews, issue updates) outside core hours divided by total events, expressed as a percentage. No universal benchmark exists, but most healthy squads see after hours activity below 15% of total weekly output. Rates consistently above 25% warrant a closer look at workload distribution and sprint planning accuracy.
• The most common mistake is treating after hours work as a sign of dedication rather than a process signal. High rates are not a badge of honor. They often indicate that work is not completing during normal hours because of blockers, unclear scope, or poor sprint calibration, none of which are solved by players simply working more.
• DevStats surfaces after hours work patterns automatically by connecting to your Git provider and issue tracker, with activity heatmaps that show when work is happening across your squad. You can compare your squad's patterns against benchmarks from 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

After hours work definition

After hours work is any engineering activity, including code commits, pull request submissions, code reviews, or issue tracker updates, that occurs outside a team's defined core working hours. It is typically measured as a percentage of total activity: After hours work % = (after hours events / total events) × 100.

For distributed or async squads, "after hours" is calculated relative to each player's local time zone, not a single global window. The metric matters beyond engineering: sustained after hours patterns increase the risk of burnout, reduce retention, and signal that your delivery process has capacity or prioritization problems that will eventually affect your roadmap commitments.

The DevStats activity heatmap visualizes when work is happening across your squad, making it straightforward to spot whether after hours patterns are isolated incidents or a consistent structural issue.

Why after hours work matters for engineering teams

When squads regularly work outside core hours, the downstream effects are predictable and compounding. Code written under fatigue produces more defects. Pull requests submitted late at night sit unreviewed until the next morning, extending PR cycle time and slowing the entire delivery pipeline. If your squad's after hours rate is climbing and you are not measuring it, you are likely missing the early signal before it becomes a retention or quality problem.

After hours work connects directly to the engineering leader's core KPIs. High rates predict missed sprint commitments, reduced throughput in subsequent sprints as players recover, and declining satisfaction scores in engagement surveys. Within the SPACE framework, after hours work is a direct proxy for the "wellbeing" dimension, sitting alongside satisfaction and efficiency as a measure of sustainable engineering capacity.

Measuring after hours work does not tell you what to do. It tells you where to look. The engineering leader decides whether the root cause is sprint overcommitment, unplanned work, blocked dependencies, or something else entirely, and acts accordingly.

How to measure after hours work

After hours work is calculated by pulling timestamped engineering events from your Git provider and issue tracker, then classifying each event as occurring inside or outside defined core hours for each player's time zone. The formula is straightforward: After hours work % = (events outside core hours / total events) × 100. You define core hours per squad or per individual, and the calculation runs against your historical commit, PR, and issue data.

No single published benchmark from DORA or the SPACE research covers after hours work as a standalone metric. Benchmarks vary by team size, on-call obligations, and whether the squad operates in a follow-the-sun model. The table below reflects qualitative signal levels used by engineering leaders in practice. DevStats's benchmarks feature lets you compare your squad's patterns against similar teams.

These thresholds are qualitative guides, not hard rules. A squad with a planned on-call rotation will naturally show higher after hours rates during incident weeks. Context from your sprint data and planning accuracy metrics is essential for interpreting what the number actually means.

After hours work in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that her backend squad's after hours activity had climbed from 12% to 31% over six weeks. She pulled the activity heatmap data and saw that the spike aligned precisely with the start of a new feature build that had been scoped mid-sprint without removing any existing work. The squad was not working more efficiently. They were absorbing unplanned scope on top of committed work, and doing it on their own time.

She ran a retrospective focused specifically on sprint scope changes, introduced a policy requiring formal scope swaps for any mid-sprint additions, and set a squad norm of no PR reviews after 7 PM local time. Over the following two sprints, after hours activity dropped back to 14%. She tracked the change using productivity and sprint completion rate as the lagging indicators to confirm the intervention held.

How to reduce after hours work

1. Audit sprint commitments against historical velocity. If your squad consistently finishes sprints with incomplete work, the commitment is too high. Pull your last six sprints of planning accuracy data and recalibrate point estimates. Overcommitment is the single most common driver of after hours work.
2. Enforce a mid-sprint scope change policy. Every unplanned item added to an active sprint should require an explicit trade-off: something else comes out. Without this guardrail, after hours work accumulates silently as players absorb the delta.
3. Review PR review queue depth at the squad level. PRs that sit unreviewed force authors to follow up after hours or re-engage late at night. Monitoring code review turnaround time as a leading indicator will surface bottlenecks before they push work into evenings.
4. Check work allocation for hidden overload. Sometimes after hours work is not about sprint scope. It is about a player carrying disproportionate allocation across multiple squads or initiatives simultaneously. DevStats surfaces allocation patterns so you can see where concentration risk exists.
5. Set explicit squad norms around async review windows. Define a window (for example, 9 AM to 5 PM local time) during which reviews and responses are expected. Players working in different time zones should have their core hours documented so after hours thresholds are calculated correctly.

After hours work vs. overtime

After hours work and overtime are related but distinct concepts: overtime is a formal HR and payroll category, while after hours work is a behavioral signal measured from engineering activity data.

Use after hours work data to diagnose delivery process health, and use overtime data for compensation and compliance decisions. They answer different questions and should not be substituted for each other.