On-call rarely feels quiet, even when your dashboards are green. There is fan noise, Slack pings, the hum of your laptop, and that subtle tension when you are watching graphs during a deployment. I started wondering what would happen if my Kubernetes clusters added their own soundtrack to that mix, and whether I would notice when something was off before I ever saw a red panel in Grafana.
That question turned into a live demo I gave at KubeCon EU, The Hills Are Alive With The Sound Of Kubernetes, which you can watch in full on YouTube, where I sonify Kubernetes events so that pods starting, crash-looping, and scaling up produce distinct sounds. By wiring a Go controller into an audio synthesis engine, I treated cluster activity like music and experimented with a different way to notice when something might be wrong.
In this post, I will walk through what sonification is, how I wired it into Kubernetes, and why it could be more than just a fun conference demo.
Sonification is the use of non-speech audio to convey information or represent data. In practical terms, it means mapping changes in a system to changes in sound so humans can perceive patterns by listening instead of just looking at charts.
You already trust sonification in other domains:
The underlying cognitive idea is often described as the cocktail party effect, first studied by Colin Cherry in the 1950s. In a noisy room, you can focus on one conversation while still noticing when someone across the room says your name. Your brain filters constant background noise and surfaces patterns that are personally relevant or emotionally salient, even when you’re not consciously paying attention.
If you treat your Kubernetes cluster as that noisy room, sonification becomes another channel where meaningful changes can stand out against a familiar sonic background. Instead of relying only on visual dashboards, you get a passive stream of sound that might make it easier to notice when something doesn’t sound right. For me, it also made me think differently about what normal looks and sounds like in a cluster.
For the KubeCon EU talk, I focused on a handful of Kubernetes events that are easy to reason about but meaningful enough that it was worth giving each its own sound: pod created, pod deleted, pod crash looping, and deployment scaling up.
Each event type mapped to a specific sound in an audio engine, with enough personality that people could tell them apart and remember them.
Here’s what it sounded like:
The point wasn’t to create a beautiful soundtrack. My idea was to define sounds that made intuitive sense and that listeners could quickly associate with cluster behavior.
During the live demo, I ran the controller against a cluster and played back the audio while triggering changes: creating and deleting workloads, forcing crash loops, and scaling a deployment. At one point, I asked the audience to close their eyes and guess what was happening in the cluster based only on the sounds. Without dashboards or kubectl output, people called out pod creation, deletion, and scaling events correctly, which felt like a good sign that the mappings were intuitive enough to pick up quickly.
To push the demo beyond simple, sequential commands, I used Chaos Mesh, a CNCF chaos engineering project for Kubernetes, to orchestrate more complex, overlapping failure scenarios. Chaos Mesh lets you define chaos experiments in Kubernetes using YAML and schedule them like any other workload, which made it easier to simulate more realistic patterns of failures and recoveries for my demo.
By combining a Chaos Mesh workflow with the sonification, I could create patterns that sounded much closer to real-world incidents than a simple, linear script. Even with multiple things happening in rapid succession, the audio remained surprisingly usable for this small set of events: you could hear when the system was calm, when it was busy, and when it was clearly unhappy.
Underneath the musical surface, the architecture of the demo is straightforward and intentionally simple: a Kubernetes cluster emitting events, a Go controller, a lightweight transport, and an audio engine.
I built a custom controller in Go that watches Kubernetes events through the Watch API. Instead of using a full operator pattern to reconcile desired state, the controller focuses on immediacy:
This is a narrow, intentional use case. I didn’t need all the machinery that comes with something like Kubebuilder, because I wasn’t managing resources, only reacting to what was already happening in the cluster.
This pattern is familiar from my day-to-day work at Fairwinds. I often end up writing small, focused bits of automation around clusters to reduce toil and surface the signals our SREs care about most, whether the output is metrics or alerts. Or, in this case, sound.
To bridge the gap between Kubernetes and audio synthesis, the controller uses OSC, a lightweight protocol designed for real-time communication between computers and audio devices. OSC runs over User Datagram Protocol (UDP), structures messages like URLs, and has very little overhead, which makes it ideal for low-latency observability signals.
In my setup, the Go controller sends OSC messages to a local port on my laptop. Each message includes a path that identifies the event type, like /k8s/pod/create or /k8s/deploy/scale, along with parameters that describe how the sound should be rendered, such as pitch, length, and effects.
If you wanted to take this further in a production context, you could imagine routing similar messages to other consumers, such as visualization engines, haptic feedback devices, or custom notification systems.
On the audio side, I used SuperCollider, a programming environment for real-time audio synthesis that is widely used by experimental musicians. SuperCollider provides a language server, a synthesis server, and an editor for loading and running sound definitions.
Within SuperCollider, I defined OSC defs, which listen for incoming OSC messages on given paths, and synth defs, which define how to generate specific sounds based on parameters. When an OSC message with path /k8s/pod/create arrives, the corresponding OSC def triggers the appropriate synth def, which uses any parameters in the message, combined with defaults, to generate a sound.
The detail work here is non-trivial. Designing sounds that are distinct enough to tell apart in a noisy environment, not so harsh that you mute them, and musically coherent (important if you care about key and harmony) turned out to be one of the hardest parts of the project. It’s relatively easy to generate random noise from Kubernetes events; it‘s much harder to create a set of sounds that are informative, intuitive, and pleasant enough that an SRE can listen to them over the course of a long incident.
For me, that was a good reminder that SRE work isn’t just about writing code. It’s about designing human interfaces to complex systems and making deliberate choices about what should be surfaced and how.
At first glance, turning Kubernetes events into music sounds like a classic conference toy. It’s fun, people remember it, and then everyone goes back to their dashboards.
Look closer, and some serious ideas start to show up.
Human brains are good at noticing changes in sound: a steady hum of normal activity will fade into the background, but a new pattern, a dissonant tone, or a sudden burst of activity stands out. When I was juggling multiple terminals during these demos, having sound in the background felt like it helped me notice when things got louder or more chaotic, even before I checked the dashboards again.
I can also imagine mapping continuous metrics, such as CPU usage, request rates, or error rates, into evolving background textures instead of static drones, or using sonified golden signals as one more way to reinforce what you see in traditional monitoring.
One of the hardest parts of operating Kubernetes platforms is building intuition about what normal looks like. Over time, experienced SREs can glance at metrics and know when something feels off; listening to your cluster as it handles deploys, traffic spikes, and chaos experiments felt like another route to that intuition for me.
It reminded me a bit of learning a musical instrument: the more you listen, the better you get at noticing when something is out of tune.
Most SREs and platform engineers already spend their days staring at dashboards, logs, and terminals, often adding even more screens during incidents. For me, having sound in the mix was just a small way to give my eyes a break and still keep a sense of what the cluster was doing in the background.
This doesn’t replace traditional observability; at best, it augments it with one more way to notice when something might be off.
This project started with a simple question: what do I actually want people to notice, and how can I present that information in a way their brains will respond to quickly. That same thinking shows up when I am designing alerting rules, choosing which metrics to promote into golden signals, or building dashboards that highlight cause-and-effect.
Behind this demo is a fair amount of Kubernetes knowledge: knowing which events are meaningful and which are background noise, understanding how to connect to the API server safely, and keeping clusters healthy enough that you can afford to run chaos experiments.
In my day job at Fairwinds, I care a lot about taking as much of that operational noise off engineers’ plates as possible so they have space to experiment, improve, and occasionally do something a little weird and fun like this.
For me, this sonification work is a small, creative example of the kind of thing I want SREs and platform engineers to have time for. The cluster is doing what it always does, the automation is in place, and the extra value comes from deciding to listen differently, to build a new mental model, and to share it with the community.
First, the easy part may not be where you expect. Writing a Kubernetes controller in Go was relatively straightforward, even though I don’t consider myself a Go specialist, while the real difficulty was sound design.
Second, constraints are your friend; limiting the initial experiment to a small set of events and running everything locally kept the scope manageable and made it possible to iterate quickly.
Third, creativity has a place in infrastructure: Kubernetes does not have to be just YAML, dashboards, and 3 a.m. pages.
If you want to try something similar in your own environment, you might start by mapping a single type of event, such as pod crash loops, to a simple sound, using a local cluster and local audio engine to avoid network complexity, and running controlled chaos experiments to hear how your system behaves under stress.
And if you’re thinking beyond audio, ask the same underlying questions: what do we want people to notice, how can we represent that in a form they’ll recognize quickly, and what toil can we remove so they can focus on interpreting and improving?
For me, that’s the through-line from creative demos like this sonification project to the SRE work I do every day: try to give people better signals, take on as much of the heavy lifting as I can, and leave more room for the kind of thoughtful, inventive work that keeps systems reliable and humans engaged.
If you’d like more of your team’s time to go toward experiments and improvements and less toward day-to-day cluster maintenance, learn more about Fairwinds Managed Kubernetes-as-a-Service and/or reach out to talk with us about your platform needs.
