Manual         — requires a human to perform it
Repetitive     — done the same way, repeatedly
Automatable    — a script/system could do it deterministically
Tactical       — no lasting value once done (vs. e.g. a design doc)
Scales with growth — grows linearly with service/user count

All five present = toil, and a real automation candidate.
Missing one or more = probably not toil, automating it may not help.

[ ] Failure mode is well-understood (not ambiguous/novel)
[ ] Safe to retry without side effects (no risk of duplicate action,
    e.g. double-charging, double-sending)
[ ] Fix is deterministic — same input, same correct action every time
[ ] Blast radius of an automated action is small and well-scoped
[ ] A circuit breaker / max-attempts limit is in place
[ ] The action itself emits a visible signal (metric/log) every time it fires
[ ] An escalation path exists for when automation can't resolve it

# Basic restart-on-failure
restartPolicy: Always

# Liveness probe — should check actual functional health, not just "is alive"
livenessProbe:
  httpGet: { path: /health/deep, port: 8080 }
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

# HPA — capacity auto-scaling as automation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

git push → CI build/test → CI updates Helm values → PR (human review) →
merge → ArgoCD/Flux detects change → applies to cluster →
continuous reconciliation (reverts manual drift automatically)