CRL production is owned by one component: crlgen. One replica is leader — standbys retry the lock and take over when the leader's database connection dies. The leader wakes on schedule and on revocation (with a short debounce), builds against one consistent generation snapshot, records a signing intent with the key service, signs, verifies, and publishes. A retry adopts the same intent rather than emitting an unaccounted second artifact — the accountability chain covers CRLs too.
Relying parties fetch GET /crl/<ca>/<generation> with ETag, Last-Modified and cache policy. Retired rollover generations keep publishing until every certificate they issued has expired — a generation you rolled away from still has relying parties.
The number that matters operationally is remaining validity. A common starting point is a 24-hour interval with 72-hour validity: the overlap is your repair window when generation fails. Alert before it closes — a CRL that expires takes every chained validation down with it, and "issuance may stop; validation must not" cuts both ways.
Now I can keep CRLs fresh and know my repair window when they aren't.