What is Change Lead Time?
Definition
Long lead times often point to bottlenecks in the review, approval, or deployment process rather than in the work of writing the change itself: a ChangeSet might be written in minutes but wait days for an available reviewer or a scheduled deployment window. Short lead times generally indicate a streamlined path from a finished change to production, with less manual coordination standing between the two. Database changes have historically had longer lead times than application code, partly because manual review and scheduled deployment windows have been more common for schema changes than for application deployments, a gap that automated policy checks and CI/CD integration are specifically meant to close.
Why Change Lead Time matters
The gap between a change being ready and a change being live is where most delivery friction hides: waiting for a reviewer, waiting for a deployment window, waiting for a manual approval that could have been automated. Change Lead Time makes that gap measurable instead of just anecdotally frustrating, and tracking it over time shows whether process improvements are actually shortening the path from finished work to production impact, rather than just feeling faster without evidence behind it.
How Change Lead Time is measured
Lead time is typically measured from when a change is considered ready, often when a ChangeSet is merged into its main branch, to when it successfully deploys. Both endpoints need a reliable timestamp, which requires the deployment side to be logged automatically rather than tracked manually, since manual tracking tends to be inconsistent exactly in the cases, rushed emergency changes, delayed releases, where the data matters most. Reporting an average alone can hide a lot; looking at the distribution shows whether most changes move quickly with a few slow outliers, or whether delay is the norm.
How Liquibase helps
Liquibase's automated deployment and Structured Logging capture the exact moment a ChangeSet deploys, giving Change Lead Time a reliable second data point without manual tracking. Combined with Policy Checks that replace manual review gates with automated ones, organizations often see lead time shrink specifically because the waiting-for-a-person step in the process gets replaced with a check that runs in seconds rather than a review that waits for someone's availability. Segmenting lead time by change type, a routine column addition versus a complex migration, often reveals more than a single blended average, since the two kinds of change rarely move through review at the same pace. Reviewing lead time alongside Change Failure Rate helps confirm a faster process isn't just cutting corners on review.
