How it works
It never stops watching.
INCIDENT
cert-manager
billing/api-tls
uses a weak 1024-bit key
DIAGNOSING
Srenix found the cause
- key size 1024 bits, below policy
- issuer and chain are healthy
- explained by rules, no AI needed
CHECKING
Safe to apply on its own
- Autonomy enabled
- Breaker closed
- Proposal present
- Action kind allowed
- Namespace not protected
- Rollback present
- Confidence ≥ 0.95
APPLYING
Reissuing the certificate
algorithm: ecdsa-p256
live state: re-checked
RESOLVED
Fixed before anyone noticed
re-diagnosed · finding cleared
verified in 140ms
An animation of a live Kubernetes cluster that plays one incident in six steps, each held long enough to read: it notices a stuck certificate, explains it with plain rules first, proposes a fix with an undo, runs its seven checks, waits for an approval (or merges itself if you allowed that) and proves the fix worked. Then the next incident starts somewhere else.