Your Git Data Predicts Burnout 6 Weeks in Advance

Developer burnout doesn't announce itself with a resignation letter. It shows up first in Git data—commits at midnight, merges on weekends, review loads that keep climbing while output quietly declines. By the time someone tells you they're burned out, you're already months too late.

"The best leading indicator of burnout isn't low output—it's high output at unusual hours. Midnight commits aren't dedication. They're a distress signal."

This guide shows you how to detect early warning signs of burnout using Git data, introduces the STRAIN Score framework for measuring burnout risk, and gives you concrete intervention strategies—so you can act before your best engineers quietly start updating their LinkedIn profiles.

The STRAIN Score: A Framework for Burnout Risk

We developed the STRAIN Score to quantify burnout risk from Git data. It's not a performance metric—it's an early warning system. STRAIN stands for six observable patterns that correlate with developer burnout:

"A STRAIN Score of 8+ predicts turnover better than any engagement survey. By the time someone rates their job satisfaction low, they've already been interviewing for weeks."

After-Hours Work: The Earliest Warning Signal

Occasional late-night coding happens. Deadlines hit, production breaks, or someone's in the zone. But pattern matters more than incidents. When after-hours work becomes systematic, it's not dedication—it's desperation.

The Burnout Progression

Burnout follows a predictable four-stage pattern:

1. Overload phase: Developer takes on extra work to meet deadlines or help the team. Feels productive, even heroic.
2. Compensation phase: Regular hours aren't enough. Work spills into evenings and weekends. "Just this once" becomes "just this sprint."
3. Chronic phase: After-hours work is the new normal. Sleep suffers. Quality drops. Cycle times increase despite more hours worked.
4. Burnout phase: Disengagement, cynicism, illness, and eventually departure. At this stage, you've already lost them.

Git data catches patterns in the compensation phase—before chronic burnout sets in. That's your intervention window. Miss it, and you're managing consequences instead of preventing them.

After-Hours Severity Levels

Not all after-hours work is equal. Context matters:

Review Overload: The Invisible Burnout Driver

"Your 'fastest' developer is probably just your most overworked. When one person does 3x the reviews of anyone else, they're not a hero—they're a single point of failure and a burnout risk."

Review overload is the most common cause of developer burnout because it's invisible work. The person doing 40 reviews a month looks "less productive" by commit counts while actually carrying the entire team. When they quit, everyone's surprised—except them.

Review Load Ratio

The review load ratio is the clearest signal of review overload:

The Expert Trap

The team's most knowledgeable developer becomes the default reviewer for complex code. Seems efficient. Creates disaster:

Review Network Analysis

Visualizing who reviews whose code reveals structural problems:

• Star pattern: One person at the center reviewing everyone's code. They're burning out. You just don't know it yet.
• Mesh pattern: Everyone reviews everyone. Distributed load, lower risk. This is the goal.
• Siloed pattern: Sub-teams only review each other. May hide imbalances within teams—check each silo separately.

CodePulse's Review Network visualization shows these patterns. Star patterns are your intervention priority.

For strategies on fixing review load imbalances, see our Review Load Balancing Guide.

Intensity Creep: The Slow Death of Sustainable Pace

Intensity creep is subtle. Each sprint, expectations tick up slightly. What was a stretch goal becomes baseline. What was baseline becomes unacceptable. A year later, your team is running 120% capacity as "normal"—and wondering why everyone seems tired.

How to Detect Intensity Creep

Look for these patterns over 3-6 month trends:

The "No Recovery" Red Flag

Healthy teams have rhythm: intense weeks followed by lighter ones. When someone never has light weeks, they're not sustainable. Look at 8-week rolling windows: if someone's bottom week is still above team average, they're overloaded.

Intervention Strategies by STRAIN Level

The whole point of measuring burnout risk is to act on it. Here's what to do at each level:

Score 4-6: Moderate Risk

• Casual check-in: "Hey, noticed some late commits this week. Everything okay? Anything blocking you during the day?"
• Don't make it a thing: This is a data point, not an accusation. You're showing you noticed and care.
• Watch for patterns: One week at moderate is fine. Three weeks in a row requires action.

Score 7-9: Elevated Risk

• 1:1 conversation about workload: "I've noticed X. Let's talk about what's on your plate."
• Review their assignments: What can be moved, delayed, or delegated?
• Redistribute review load: If they're doing 3x average reviews, that's the first thing to fix.
• Set explicit boundaries: "I don't want to see commits after 7 PM. If there's that much work, we have a planning problem."

Score 10-12: Critical Risk

• Immediate workload reduction: Remove responsibilities now. Don't wait for the sprint to end.
• Enforce time off: "Take Friday off. That's not optional."
• Direct conversation about sustainability: "I'm concerned about your current pace. Let's fix this together."
• Consider extended leave: If chronic, a week off may not be enough. Two weeks of true disconnection may be necessary.
• Fix the system, not the person: Why did it get this bad? What's wrong with your planning, staffing, or expectations?

Building a Culture That Prevents Burnout

Detection is good. Prevention is better. The best burnout strategy is a culture where it's hard to burn out in the first place.

Set Boundaries Organizationally

Individual developers can't set boundaries themselves—they need organizational support and cover:

• No weekend deploys: Unless it's an incident, production changes wait until Monday. This is non-negotiable.
• Review SLAs during business hours: PRs submitted at 5 PM don't get same-day reviews. That's not a failure—that's healthy.
• On-call rotation: After-hours responsibility rotates. No one person carries it indefinitely.
• Celebrate sustainable pace: Publicly recognize efficiency during work hours. Never celebrate heroic overtime.

Make Workload Visible

Burnout thrives in darkness. Making workload visible helps everyone:

• Share review load metrics in standups: "Sarah's been doing 3x average reviews this sprint. Let's redistribute."
• Track after-hours trends as a team metric: Not individual surveillance—team health indicator.
• Include sustainability in retrospectives: "Are we working at a sustainable pace?" should be asked every sprint.

Kill the Hero Culture

"If your team has heroes, you have a broken system wearing a cape. Heroes are single points of failure. Celebrate the quiet engineers who deliver on time during work hours—they're the ones keeping you sustainable."

Hero culture glorifies unsustainable behavior. The developer who stayed up all night to fix the release gets public praise. The developer who flagged the risk two weeks ago and was ignored gets nothing. This incentivizes exactly the wrong behavior.

• Celebrate prevention: The best save is the one that never happened.
• Question heroics: "Why did this require an all-nighter? What broke in our process?"
• Protect the reliable: Steady performers are your foundation. Don't burn them out covering for chaos.

Action Plan: Start Measuring This Week

This Week

1. Calculate current STRAIN Scores: Review the six factors for each team member. Who's at elevated or critical risk right now?
2. Check Risky Changes: How many after-hours merges happened last week? Who's responsible for them?
3. Review load distribution: In Review Network, is anyone a "star" pattern? Is anyone doing 3x+ reviews?

This Month

1. Have 1:1s with elevated-risk developers: Data-informed conversations, not accusations.
2. Redistribute review load: Train additional reviewers for areas with single experts.
3. Set up alerts: Create Alert Rules for sustained after-hours patterns and review overload.

Ongoing

1. Monthly STRAIN reviews: Calculate and track scores. Trends matter more than absolutes.
2. Sustainability in retros: Make "Are we sustainable?" a standing question.
3. Celebrate sustainable wins: Recognize developers who deliver excellent work during reasonable hours.

Burnout is easier to prevent than recover from. The signals are in your Git data. The question is whether you're watching—and whether you're willing to act on what you see.

For more on building healthy, data-informed teams, see our guides on Measuring Team Performance Without Micromanaging, Engineering Manager Metrics Guide, and Review Load Balancing.