2026-08-25

Clearer alerts, and control over what you receive

#kubernetes  #monitoring  #alerting 

We’ve been working on making the alerts you receive from Skyscrapers clearer and more useful. Many of them used to come straight from generic Kubernetes tooling, technically accurate, but not always easy to act on without deep Kubernetes knowledge. We’ve rewritten the most common ones with plain-language descriptions and direct links to our runbooks, so it’s clearer what’s happening and what to do about it.

What changes for you

You can now, together with us, tune what you receive:

  • Turn off specific alerts that don’t apply to your setup
  • Adjust the severity of an alert if our default doesn’t match how urgent it actually is for you

These changes are made as a reviewable change to your cluster configuration, not a hidden mute button, so everyone on your team can see what’s been adjusted and why.

Alerts posted to your Slack channel also show more context at a glance now: severity, namespace, how long it’s been firing, a recommended action when we have one, and a direct link to the relevant dashboard, alongside the existing silence and runbook buttons. We also fixed the silence button so it actually covers the next occurrence of the same issue, rather than a single overly specific match.

We need your feedback

This is a first step, not a finished product. The alerts we rewrote and the defaults we chose are based on our own judgment of what matters, but you know your systems better than we do. If something still feels noisy, unclear, or miscategorized, we want to hear about it.

We’ll be scheduling a follow-up with you to walk through your current alert setup together, hear what’s working and what isn’t, and adjust the configuration based on your feedback. This isn’t a one-time announcement, it’s the start of an ongoing conversation about your alerting.