Revoking a certificate is two events, and confusing them is how relying parties keep trusting a key you killed. POST /v1/revocations takes revoke (permanent, with an RFC 5280 reason code), or hold/release for temporary suspension. The action history is append-only — effective status is the latest action, and the full history stays visible on the certificate forever.
The revocation commits immediately, emits a lifecycle event, and wakes the CRL controller. But the database knowing is not the world knowing: the console deliberately shows database status and publication convergence separately. Treat the operation as complete for relying parties only when every required target reports an artifact newer than the revocation.
Use holds sparingly, and understand the cache problem: a relying party that fetched a CRL between your hold and your release saw a revoked certificate, and will keep believing it until its cached CRL expires. A hold is not a pause button the world observes in real time.
Now I can revoke a certificate and say when the world actually knows.