RunBeat Streaming User Guide

Broadcast-critical stream relay, monitoring, and automatic failover — designed for stations that can't afford to go off air.

Docs → RunBeat Streaming

Overview

RunBeat Streaming is a stream relay, monitoring, and failover platform built for radio stations that need reliable audio delivery to DAB MUX sites, Revma, and other destinations. It sits between your playout system and your distribution endpoints, providing real-time monitoring, automatic backup audio failover, per-output transcoding, and instant alerts when something goes wrong.

Streaming is hosted at streaming.runbeatmedia.co.uk and is multi-tenant, with each organisation operating in its own isolated account.

Getting Started

Visit streaming.runbeatmedia.co.uk and sign up with your email or log in with your RunBeat (Pulse) account via SSO.

First steps

  1. Create a station — Add your radio station with a name and description.
  2. Add a mount — Configure the source mount point that your playout system connects to (e.g. /broadcast-feed).
  3. Add relay outputs — Configure where the audio should be delivered (DAB MUX, Revma, backup Icecast, etc.).
  4. Upload backup audio — Upload an MP3 file as emergency fallback in case your playout system goes down.
  5. Configure alerts — Set up email, Slack, or webhook notifications for outages.
  6. Go live — Point your playout system at the mount URL and start broadcasting.

Dashboard

The dashboard provides an at-a-glance view of all your stations and mounts. Each mount shows:

  • Source status (live/offline) with colour-coded indicator.
  • Listener count.
  • Connected relay outputs with individual status.
  • Current now-playing metadata.
  • Last checked timestamp (polling runs every 5 seconds).

Stations & Mounts

A station represents a radio service. Each station can have one or more mounts — these are the Icecast mount points that your playout system connects to as a source.

Mount configuration includes:

  • Mount path — The Icecast mount point path (e.g. /broadcast-feed).
  • Display name — A friendly name shown in the dashboard.
  • Expected source IP — Optional whitelist of IPs allowed to connect as source.
  • Server type — The audio format (Icecast, Shoutcast).

Relay Outputs

Relay outputs define where your audio is delivered. Each mount can have multiple outputs — for example, one to your DAB MUX, one to Revma, and one to a backup Icecast server.

Output configuration includes:

  • Name — A descriptive label (e.g. "DAB MUX Primary", "Revma Relay").
  • Output type — Pull, Push, or Both (see below).
  • Push URL — Destination URL for push outputs.
  • Push credentials — Username and password for authenticated push destinations.
  • Push protocol — Icecast or Shoutcast protocol.
  • Expected IPs — For pull outputs, the IPs expected to connect.
  • Priority — Ordering for display and alerting.
  • Critical flag — Mark outputs as critical for escalation alerting.
  • Transcoding — Optional per-output codec/bitrate conversion.

Output Types

TypeHow it worksBest for
PullThe destination connects to your Icecast mount and pulls the audio stream. Streaming monitors the connection by checking Icecast's listener list.DAB MUX sites that connect to you.
PushStreaming uses FFmpeg to push the audio to a remote Icecast/Shoutcast server. Streaming manages the FFmpeg process and monitors its health.Revma, backup servers, CDN ingest points.
BothMonitors both a pull connection AND maintains a push process. Useful when you need redundancy.Critical outputs where you want belt-and-braces.

Per-Output Transcoding

Each push output can optionally transcode the audio to a different codec and bitrate. This is useful when your playout system outputs high-quality audio but a destination requires a specific format.

Transcoding options:

  • Codec — MP3, AAC, Ogg Vorbis, Opus.
  • Bitrate — 32–320 kbps.
  • Sample rate — 22050, 44100, or 48000 Hz.
  • Channels — Mono or stereo.

Transcoding is handled by FFmpeg processes managed by the platform. Each output runs its own independent FFmpeg instance.

Real-Time Monitoring

Streaming polls your Icecast server every 5 seconds to check the status of every mount and output. The monitoring system tracks:

  • Source status — Is your playout system connected and sending audio?
  • Output connections — Is each pull destination connected? Is each push process running?
  • Listener count — How many listeners are connected to each mount.
  • Bytes sent — Data throughput per output.
  • FFmpeg state — For push outputs: running, reconnecting, or failed.
  • Consecutive failures — How many poll cycles an output has been disconnected.
  • Silence detection — Detects when audio is present but silent (no actual content).

Backup Audio & Failover

Upload an MP3 file as backup audio for each mount. If your playout system disconnects (source goes offline), the platform automatically starts playing the backup audio to all connected outputs — keeping your station on air.

How failover works

  1. Source disconnects → alert fired, backup audio starts playing within seconds.
  2. Backup audio loops continuously until the source reconnects.
  3. Source reconnects → backup audio stops, live audio resumes automatically.
  4. Silence detected → if enabled, backup audio can also trigger on silence (audio present but no content).

Backup audio files are stored in S3 with server-side encryption.

Now Playing Metadata

Streaming supports multiple metadata sources for now-playing information:

  • Myriad OCP — Receives now-playing data from Myriad playout via the OCP protocol.
  • API push — Your playout system pushes metadata via a REST API endpoint.
  • Icecast in-band — Reads metadata from the Icecast stream itself.
  • RunBeat Pulse — Polls now-playing data from a linked Pulse station.
  • Webhook pull — Fetches metadata from a configured URL on a schedule.

Now-playing data is available via a public API endpoint (no auth required) for use by station websites, apps, and DAB PAD systems.

Alerts & Escalation

When a monitored event occurs (source disconnect, output disconnect, silence detected), the alert engine fires notifications:

  • Email — Sent to configured recipients.
  • Slack — Posted to a configured Slack webhook.
  • Webhook — HTTP POST to a custom URL with event details.

Escalation

If an alert is not resolved within a configurable time window, it escalates to additional recipients. This ensures critical outages don't go unnoticed if the primary contact is unavailable.

Resolution alerts

When a previously-alerted issue resolves (source reconnects, output reconnects), a resolution notification is sent automatically — including the total downtime duration.

Alert Preferences

Configure per-user alert preferences:

  • Which event types to receive (source down, output down, silence, backup activated).
  • Which channels to use (email, Slack, webhook).
  • Quiet hours — suppress non-critical alerts during specified times.
  • Escalation delay — how long before escalation triggers.

Uptime Reporting

The Uptime Report page shows historical reliability data for each mount and output:

  • Daily uptime percentage.
  • Total downtime minutes per day.
  • Number of outage events.
  • Average time to recovery.
  • Date range filtering (7 days, 30 days, 90 days, custom).

Use uptime reports to demonstrate SLA compliance to MUX operators or to identify recurring issues.

Event Log

A chronological log of every connection event — source connects/disconnects, output connects/disconnects, silence events, backup activations, and FFmpeg process state changes. Each event records the timestamp, event type, affected mount/output, client IP, and any associated metadata.

Integrations

  • Myriad OCP — Receive now-playing metadata from Myriad playout systems via the OCP (Open Communications Protocol).
  • RunBeat Pulse — Link a mount to a Pulse station for automatic now-playing metadata sync.
  • External monitoring — Public monitoring endpoints compatible with Uptime Kuma, Pingdom, and similar tools (see below).

Public Monitoring Endpoint

Each mount has a public monitoring URL (no authentication required) that returns the current status in JSON format. Use this with external monitoring tools like Uptime Kuma or Pingdom:

GET /api/monitor/{mount-path}

Response (200 = up, 503 = down):
{
  "status": "up",
  "mount": "Broadcast Feed",
  "source_live": true,
  "listeners": 3,
  "format": "audio/mpeg"
}

Authentication

RunBeat Streaming supports dual authentication:

  • Pulse SSO — If you use RunBeat Pulse, log in with your existing Pulse credentials (Microsoft 365 via Cognito).
  • Standalone — Email and password registration for users who don't use other RunBeat products.

User Roles

RoleAccess
Account AdminFull access — stations, mounts, outputs, backup audio, alerts, users, settings.
EngineerManage mounts and outputs, configure backup audio, view monitoring. Cannot manage users or billing.
ViewerView-only access to dashboard, monitoring, and reports. Cannot modify configuration.

Multi-Tenancy

Each organisation operates in a fully isolated account. Data, configuration, and monitoring are completely separated between accounts. A single user can belong to multiple accounts (e.g. an engineer managing streaming for several station groups) and switch between them from the account selector.