A startup probe gives a container a separate initialization contract. While that configured probe has not succeeded, Kubernetes does not execute the container’s liveness or readiness probes. This is stronger and more specific than ignoring some liveness failures during a grace period: those other checks have not begun. Once startup succeeds, ordinary ongoing health and readiness behavior takes over. ...
A change that races to zero traffic but lands when nobody is watching trades one risk for another. The best window is one where the operators responsible can actually attend. Traffic is only part of the math Deploying at the absolute quietest hour minimizes how many users feel the change, but it collides with the people problem: the operator is most likely asleep, unreachable, or already covering another incident. If the rollout breaks at 3 a.m. and nobody is watching, a silent failure can run for hours before a human reads it. Least-traffic is a good starting estimate, but it is a traffic answer, not a risk answer. Balance reduced exposure against the ability to react, and prefer a window where you can actually observe the result. ...
A rota can distribute responsibility, but equal shift counts do not guarantee equal burden. Review nighttime pages, incident effort, recovery time, and reliable backup alongside the schedule. A job that is shared On-call work is a job that belongs to a team, not to one hero. A rotation turns ‘whoever was last awake’ into a defined roster and a schedule, so responsibility is explicit and no one is assumed to carry the whole queue indefinitely. The schedule itself — a weekly handoff, a backup/secondary on-call, a follow-the-sun structure across sites — is how you keep the obligation sustainable without letting it turn into a possession. Don’t let the urgency of tonight’s page decide who owns tomorrow; the rotation decides on purpose, ahead of time. ...
A completed backup job establishes that the backup process produced an artifact. A restore rehearsal establishes whether that artifact, the available tooling, and the required environment can produce a usable system. These are different claims. Recovery evidence should identify the backup used, the state recovered, the dependencies supplied, and the time needed to make the result useful to the application. ...
S3 Versioning retains multiple versions under one key, making many accidental overwrites and ordinary deletes recoverable while the required version still exists. It does not protect against every deletion or provide an independent backup by itself. Retention, permissions, encryption-key availability, and restoration procedures determine whether the saved history can actually recover the application. ...
Pinning a container base by digest fixes the referenced image object instead of relying on a movable tag. That removes one source of unexpected build changes, but it does not make every derived image or running instance identical. Application source, build arguments, fetched dependencies, target platform, runtime configuration, and persistent data can still change what gets built and how it behaves. ...
An idle timeout closes a connection after a defined period without qualifying activity. It is a resource policy, not proof that the client disappeared. Quiet connections can belong to healthy clients; the useful question is which activity resets which timer, and what the protocol allows after closure. ...
An error budget makes a reliability agreement usable during planning. Product and operations choose an objective, measure failures against it, and agree what changes when the allowance is exhausted. The number supports that agreement; it does not predict whether tomorrow’s deployment will cause an incident. Shipping a release creates risk, while observed bad events consume the measured budget. ...