Operations

Dead air: what causes it and how stations prevent it

Every way an online radio station goes silent — source drops, empty schedules, missing files, expired feeds — and the fallback layers that stop each one.

Updated August 18, 2026 · 5 min read

Dead air is silence going out to listeners. It is the oldest fear in broadcasting, and in online radio it is more dangerous than it was on FM, because a silent transmitter is still a transmitter and a silent stream is often a *disconnected* stream — players give up, listeners close the tab, and the audience does not come back automatically when you do.

Nearly all of it comes from a handful of causes, and each one has a specific answer.

The causes, in order of frequency

A live source disconnects. A presenter's internet drops, a laptop sleeps, an application crashes, someone closes the lid at the end of a show without stopping the stream. The station was being fed by that connection and now it is not.

The schedule has a hole. Nothing is scheduled at 04:00 on a Sunday because nobody thought about 04:00 on a Sunday. This is the most common cause on new stations and the most embarrassing, because it is entirely a planning failure and it always happens at the hour with the fewest listeners and the most insomniacs.

A scheduled item points at nothing. The show is scheduled, the playlist is assigned, and the playlist is empty — or the files it references were deleted, or moved, or the storage they live on is unreachable.

An external feed is down. A news bulletin pinned to the top of the hour lives at somebody else's URL, and their server is having a bad morning.

A clock cannot fill its time. Every slot is pinned to a minute, so there is no rotation to fill the gaps between them, and the hour is mostly nothing.

The playout process died. Rare on managed platforms, common on a PC in a cupboard, and the reason a PC in a cupboard is not a broadcast plan.

Fallback is a stack, not a switch

The right mental model is layers. Each one catches what the layer above it dropped, and the bottom layer must be something that cannot fail.

Layer 1 — the live source. Whoever is on air.

Layer 2 — automation. The moment a live source disconnects, scheduled automation takes over. The important detail is *where* it resumes: from the current schedule position, meaning whatever should be on air at that minute — not from where it was interrupted two hours ago. Resuming from the interruption point means a station that spends the rest of the day playing yesterday afternoon.

Layer 3 — the fallback playlist. When the schedule has nothing to say — a hole, an empty playlist, a clock that cannot fill its hour — something has to play. A fallback rotation with a few hundred safe tracks in it is the cheapest insurance in radio and takes ten minutes to set up.

Layer 4 — a fallback file. A single long file, on the machine that does the streaming, that plays when even the fallback playlist is unreachable. Unglamorous, and it is the difference between a bad hour and a dead one.

Skipping a layer is fine as long as you know which one you skipped and why.

Silence detection

Silence detection is a separate protection, because some dead air is not a disconnection. The stream is up, the encoder is running, the meters are moving, and what is going out is nothing at all.

Causes: a file that is silent, a source connected to the wrong input, a mixer fader down, a hardware output muted. To every automated system in the chain, this looks like a station working perfectly.

Detection means measuring the audio and acting when it stays below a threshold for longer than a set time. The threshold matters — silence between tracks is normal, a quiet passage in a piece of music is normal, and a detector set too aggressively will trip during a pause in a documentary. Several seconds is the usual window.

The action is either to alert someone or to switch to fallback. Both are better than the alternative, which is a listener emailing you at lunchtime to say the station has been off since breakfast.

Design decisions that prevent most of it

Never let something be cut off mid-item. Systems that hard-cut at a boundary create small ugly moments constantly, and people learn to design around the system instead of around the show.

Step over failures rather than waiting for them. If an external bulletin's URL does not respond, play the next thing immediately. A slot waiting hopefully for someone else's server is dead air with an explanation.

Make the failure visible where it happened. A feed that failed at 07:00 should say so on the page that owns it, not only in a log. Most stations discover a broken feed weeks later.

Kick, do not wait. When a presenter's software vanishes without closing the connection cleanly, the server may hold the session open — receiving nothing and passing on nothing. An operator needs to be able to end that session and return the station to automation without waiting for a timeout.

Schedule the whole week, including the parts nobody listens to. Then check it. An hour with no event is the single easiest cause to fix and the easiest to forget.

Monitoring

You cannot rely on listeners to tell you. Most will not, and by the time one does it has usually been hours.

The minimum worth having is something that connects to your public stream from outside your own network and confirms audio is present — not that the server responds, which it will do quite happily while broadcasting silence. Plenty of external services do this for a few pounds a month, and it is the cheapest thing on this page.

Then check listener numbers. A graph that goes to zero and stays there says more than any error log, because it measures what actually matters: whether anyone is hearing you.

Frequently asked questions

What counts as dead air?

Any silence going to listeners that was not intended. In practice, more than a few seconds — the gap between two tracks is not dead air, but ten seconds of nothing is, and thirty seconds will lose you listeners who assume the stream is broken.

Does the station keep playing if my broadcasting software crashes?

On a properly configured station, yes. The live source disconnects and automation resumes from the current schedule position. Listeners hear a short gap rather than silence, and no one has to intervene.

Why does my station go quiet at the same time every week?

Almost certainly a hole in the schedule at that hour. Check the week's events for a gap, and set a fallback playlist so a future gap is covered even before you notice it.

What is a fallback playlist?

A rotation the station drops to when the schedule has nothing playable — a hole, an empty playlist, missing files. A few hundred safe tracks is enough, and it should be the least surprising music you have.

Should I be alerted or should the station switch automatically?

Both. Automatic switching keeps listeners; the alert is what gets the real problem fixed. A station that silently fails over forever is a station whose schedule stops meaning anything.

See it for real

Stop reading about it — watch it run.

Everything this page describes as a concept is a screen in RadioHost Studio: the clockwheel editor, the week grid, the voice-track recorder, the play log. The guided tour walks through all of them on a station that is on air, with no account and nothing to install.

  • About 12 minutes
  • No account, no credit card
  • Real screens, not mockups