The finding
Of 7,654 customer-facing merged PRs, 20.3% shipped with no matching docs update, and 6.3% were still undocumented more than 30 days later, meaning they were effectively never documented. Yet 35.2% of customer-facing changes were structured enough that a diff-aware tool could have drafted the update automatically. The bottleneck is not writing. It is noticing.
How much documentation debt is real
Documentation debt is not a vague complaint. It is the measurable gap between changes that reached customers and changes that reached the docs. Across the dataset, most customer-facing work did eventually get documented, but a durable slice never did.
When docs did land, they usually landed fast: a median of 0.5 days after merge. But the tail is long. The slowest 10 percent of updates took 11 days or more, which is more than enough time for a customer to hit an article that no longer matches the product.
How much of it could be automated
Not every change is mechanically documentable. Some need a screenshot, a judgment call, or product context a diff cannot supply. But a large share is exactly the structured surface, API changes, config, CLI flags, and endpoints, that a tool can draft from the pull request itself.
That second bar is the real story: of the changes that never got docs, 32.2% could have been drafted automatically. This is doc debt that existed only because no one connected the merge to the article, not because the work was hard.
What doing it by hand costs
Put a price on just the automatable work. Writing docs by hand for the 2,694 auto-draftable PRs in this sample would take roughly 898 to 1,796 hours of skilled time.
How we measured it
Every figure on this page is computed directly from the audit dataset, not estimated. Here is exactly what was counted.
| Repositories analyzed | 514 |
| Merged PRs audited | 29,917 |
| Customer-facing PRs | 7,654 (25.6% of all PRs) |
| Classified internal | 9,163 |
| Classified bug fix | 6,583 |
| Classified unclear | 6,517 |
- A PR counts as documented when a docs commit is found in the repo after the merge.
- "Customer-facing" means the change was classified as a customer_facing_feature, the surface that warrants a docs update.
- "Never documented" means undocumented and merged more than 30 days before the most recent merge in the dataset, so the window to document it had fully passed.
- "Auto-draftable" means the change was structured enough to draft docs from the diff alone.
Frequently asked questions
How many companies actually keep their documentation up to date?
In an audit of 29,917 merged PRs across 514 open-source SaaS repos, 20.3% of customer-facing changes shipped with no docs update and 6.3% were never documented at all. Most teams document most changes, but a steady minority always slips.
Is documentation debt a real, measurable problem?
Yes. It is the gap between changes that reached customers and changes that reached the docs. In this dataset, 1,554 customer-facing PRs shipped undocumented, and the slowest 10 percent of updates that did land took 11 days or more.
How much of technical documentation can be automated?
About 35.2% of customer-facing changes were structured enough to draft docs from the pull request diff alone. Among the changes that never got documented, 32.2% were auto-draftable, so most of that debt was avoidable.
What does it cost to keep product documentation updated?
Writing docs by hand for just the automatable PRs in this sample would take roughly 898 to 1,796 hours, about $67,350 to $134,700 of skilled time, assuming 20 to 40 minutes per update at $75 per hour.
Can documentation be generated automatically from a GitHub pull request?
For structured changes, yes. API updates, config, CLI flags, and endpoints can be drafted from the diff. A human still approves before publishing. That approval-in-the-loop model is what keeps automated docs accurate.