KTLO stands for "keep the lights on." It is the engineering work that keeps software you have already shipped running: bug fixes, dependency upgrades, config changes, on-call toil, platform migrations, and the small repairs nobody puts on a roadmap. Your KTLO ratio is the share of engineering effort going into that upkeep instead of into something new.
Every team has KTLO. Most teams cannot tell you what theirs is.
#Where the term comes from
"Keep the lights on" is borrowed from facilities and IT budgeting, where spend splits into run and change: the money that keeps the building open versus the money that makes it different. Finance has tracked that split for decades because it answers a blunt question. If the run cost keeps climbing, the change budget shrinks, and eventually you are paying a full team to stand still.
Engineering inherited the phrase and the anxiety behind it. The version you will hear in a planning meeting is usually some form of: why does it feel like we shipped nothing this quarter when everyone was busy?
You will also see it written as BAU ("business as usual"), run work, or maintenance load. They point at roughly the same thing.
#What counts as KTLO
There is no standard definition, which is the first honest thing to say about it. But most teams draw the line in a similar place.
Usually KTLO:
- Bug fixes in shipped features
- Dependency and framework upgrades
- Security patches
- Config, infrastructure, and environment changes
- Incident response and the follow-up fixes
- Migrations forced by a vendor, a deprecation, or an end-of-life
- Flaky test repair and CI babysitting
Usually not KTLO:
- New features
- New products or surfaces
- Experiments and prototypes
- Performance or reliability work that unlocks something new rather than restoring what broke
Genuinely ambiguous:
- Refactoring. It is upkeep if you are paying down a mess, and investment if you are clearing the way for the next feature. The same diff can be either.
- Documentation
- Test coverage added after the fact
- Developer tooling
Do not spend a week arguing the boundary. Pick a line, write it down, and keep it stable, because the whole value of the number is in comparing it to itself over time. A KTLO ratio you redefine every quarter is not a metric, it is a mood.
#The number nobody can actually produce
Ask a team what their KTLO ratio is and you will get one of three answers: a shrug, a number from a survey, or a number from Jira.
The survey number is a memory test. You are asking engineers to recall, at the end of a quarter, roughly what proportion of their attention went to upkeep. People systematically over-report whatever annoyed them most, which is nearly always the maintenance.
The Jira number is a labelling test. It is only as good as the discipline of ticketing, and the work that most defines KTLO, the twenty-minute fix that never got a ticket, is exactly the work that never makes it in. Teams with a heavy KTLO load are usually the teams with the least time to keep the tracker tidy, so the metric gets least accurate precisely when it matters most.
Both approaches share a flaw: they measure intent, not output. They tell you what people meant to work on.
#Measuring KTLO from merged pull requests
There is a more boring source of truth sitting in your Git history. Every merged pull request is a completed unit of work with a diff attached, and the diff usually says what kind of work it was. Files touched, tests changed, whether it edits a lockfile, whether it only moves configuration around.
Classify each merged PR, then the ratio falls out:
1KTLO ratio = maintenance PRs / all merged PRs
Coderbuds does this automatically, sorting every merged pull request into categories like feature, bug fix, dependency update, configuration, test-only, and bulk migration. Group everything that is not a feature and you have a KTLO ratio that nobody had to remember, label, or self-report, running week over week.
The categories are visible on the Activity page as a composition breakdown, so "we spent September on dependency upgrades" stops being a feeling and becomes a bar you can point at in a planning meeting.
#Three ways this number will mislead you
It counts pull requests, not effort. A one-line Dependabot bump and a 4,000-line database migration both count as one PR. If your maintenance work skews large and your feature work skews small, a PR-count ratio will understate your KTLO badly. Weighting by lines changed swaps one distortion for another, since a mechanical rename is enormous and trivial. The practical answer is to look at both and distrust either alone, for the same reason line counts fail as a productivity measure.
Bot traffic inflates it. If Dependabot or Renovate opens and merges thirty PRs a week, your KTLO ratio is mostly a report on your bot's schedule. Split human-authored work from automated work before you read anything into the number. A team whose upgrade pipeline is fully automated is in a better position than one with a low KTLO ratio and eighteen months of unpatched dependencies, and a naive ratio says the opposite.
Zero is not the goal. This is the failure mode that does real damage. Once KTLO becomes a number on a slide, the obvious move is to drive it down, and the fastest way to drive it down is to stop doing maintenance. That works for about two quarters. Then the upgrade you skipped becomes a migration, the migration becomes an incident, and the ratio you were optimising spikes past where it started. A team at 5% KTLO is usually not efficient, it is accruing a debt with a variable interest rate.
#So what is a good KTLO ratio?
Anyone quoting you a universal benchmark is guessing. The right level depends on things that vary enormously between teams:
- Age of the system. A codebase with ten years of customers behind it carries obligations a six-month-old one does not.
- What the team owns. Platform and infrastructure teams are supposed to run high. Upkeep is the product.
- Surface area per engineer. Five engineers maintaining forty services will run higher than twenty engineers maintaining four.
- Automation maturity. Automated dependency management moves work from invisible toil into visible, cheap PRs, which can raise the ratio while lowering the cost.
The level is not the signal. The trend is. Three things worth reacting to:
- KTLO climbing while headcount is flat. Your maintenance burden is growing faster than your capacity to absorb it. This is the one that ends in a rewrite proposal eighteen months later.
- KTLO spiking in one repository. Usually a specific system asking for attention, not a team-wide problem. Worth finding before it generalises.
- KTLO collapsing suddenly. Rarely good news. Either the work moved somewhere you cannot see it, or it stopped happening.
#Reducing KTLO without pretending it away
Automate the mechanical parts. Dependency updates, security patches, and routine upgrades should not consume human judgement. Getting these onto a bot does not lower the true cost to zero, but it moves the work out of an engineer's week.
Fix the sources, not the instances. If the same service generates a third of your bug fixes, the useful project is that service, not the bugs. A per-repository breakdown of maintenance work usually points at one or two obvious culprits.
Give it a budget instead of a target. Teams that allocate a fixed share of each cycle to upkeep, and defend it, tend to keep the ratio stable. Teams that treat maintenance as what you do with leftover time watch it compound until it is not optional any more.
Make it visible before it is urgent. The reason KTLO turns into a crisis is that nobody watches it until a quarter goes missing. A number your team sees weekly is a number you can steer. A number you calculate during a postmortem is a number you can only explain.
#Frequently asked questions
What does KTLO stand for? Keep the lights on. It refers to engineering work that maintains existing systems rather than building new capability.
Is KTLO the same as technical debt? No, though they are related. Technical debt is a property of the codebase: shortcuts and compromises that make future change harder. KTLO is a category of work. Technical debt is one of the things that generates KTLO, but plenty of upkeep, like a framework's end-of-life, has nothing to do with debt you took on.
What is the difference between KTLO and BAU? In most engineering contexts they are used interchangeably. BAU ("business as usual") is the broader business term and sometimes includes routine operational work beyond software. KTLO is the version that stuck in engineering.
How do I measure KTLO without ticket discipline? Categorise merged pull requests instead of tickets. The Git history records what actually shipped rather than what was planned, and it does not depend on anyone remembering to label anything.
Should KTLO be as low as possible? No. A very low ratio usually means maintenance is being deferred rather than avoided, and deferred maintenance gets more expensive, not less. Stability of the ratio over time is a better goal than minimising it.
#Where to go next
If you are building a wider measurement picture around this, DORA metrics cover the delivery side of the same question, and reporting engineering metrics to a board covers how to present a ratio like this one without it being read as a productivity score.
