What matters most
| Signal | Why it matters |
|---|---|
| Severity | Sets initial priority, but does not replace object context. |
| Repetition | Repeated warnings may still be low impact when object health is stable. |
| Related object | Links the event to the workload, node, namespace or policy path that explains it. |
| Current object state | Always compare the event against readiness, restarts and recent activity. |
How to interpret warning patterns
- Stable warnings with no restart growth often indicate noise, history or low-impact churn.
- Warnings paired with declining readiness or repeated rollout lag are more serious.
- Access-related warnings should be compared with the response shape before calling it an outage.
WarningEvent volume alone is not a reliable proxy for impact. Object state change matters more than count.