Skip to content

// 04 · Service

WebRTC capacity and cost operations

Real-time systems degrade quietly: an encoder falls back to software, a provider reprices, a model is deprecated. Monitoring aimed at the counters that actually move, alerting on the degradation that precedes failure, and a person who answers inside stated hours.

  • WebRTC
  • WHIP
  • LiveKit
  • MediaMTX
  • GStreamer
  • FFmpeg
Start with a Sprint

// The problem

Why this is hard

The failure mode of a live system that is being watched badly is not an outage. It is months of working while wrong.

A dashboard is a poor witness here because the numbers that look reassuring are the ones that do not bind. GPU utilisation sits in single digits while the hardware encoder is out of sessions, because utilisation and session count are unrelated — so the box is full at 8% and the monitor says there is room for an order of magnitude more. A memory limit somebody guessed reports that guess back forever, and every incident it causes looks like a workload problem rather than a configuration one. Cost per minute drifts because nothing is watching a number that only appears on an invoice.

And the spike that takes the fleet down is not peak traffic. It is a simultaneous cold start — every pipeline launching at once after a deploy, a crash or a host reboot — which a gradual ramp never reproduces and which happens in production on an ordinary Tuesday.

// What we build

What you get

The counters that actually bind

Hardware encoder sessions, per-stream cores and memory, cost per minute — the quantities that reach a ceiling. Utilisation is watched too, but never as the alert: it reads 8% on a box that is already full.

Alerts derived from a measurement

Limits set from a measured peak with margin, alerts set below the limits, in that order. A threshold picked before anything was measured is a guess that will report itself back to you as an incident.

The early signal, not the hard failure

Write stalls, page-cache eviction and rising latency usually precede a hard failure by minutes. Where they do, that is the alert — it buys the time a resource threshold does not.

Capacity re-measured as the fleet grows

The cold-start ceiling is lower than the steady-state one and it is the number production meets on its next deploy. It moves as services are added, so it gets re-measured rather than assumed.

// How it fits together

The system we build

  1. Instrumentthe binding counters
  2. Measurepeak, then soak
  3. Limitfrom the measurement
  4. Alertbelow the limit
  5. Respondstated hours
A representative shape — abstract by design; we build it in your stack and your conventions.

// Deliverables

  • Monitoring on the counters that bind
  • Alerts derived from measured limits
  • Capacity re-measured as the fleet grows
  • Incident response, stated hours

// How we work

From prototype to production, in four moves.

01

Discovery

We map the problem, the data, and the eval that defines "done".

02

Prototype

A working slice in weeks — real model, real data, measured.

03

Production

Hardened, observable, evaluable. Shipped where users live.

04

Scale

Cost, latency and reliability tuned as load and scope grow.

// Typical engagement

What it takes to work together

  • Architecture Sprint

    $2–4kfixed · 1–2 wks

    1–2 weeks

    De-risk before you build — measured latency budget, architecture, and a costed fix list. Credited against the build.

  • Build

    from$12kfixed scope or pod

    typically 1–3 months

    Ship it end-to-end and take it to production, in your repo and conventions.

  • Run & Scale

    from$1.5k/ month

    ongoing

    Keep it working after launch — evals, latency and cost tracking, and incident response.

Indicative ranges — the final price and timeline depend on your project's scope, complexity, and integrations. A paid Architecture Sprint pins them down.

// FAQ

Common questions

No, and we will not describe it as though it were. Incident response runs in stated business hours, agreed in writing before the retainer starts. What the engagement buys outside those hours is a system that fails loudly and early rather than silently — alerts that fire minutes before a hard failure, and limits derived from measurements, so the fleet is not depending on someone being awake.

Usually what is being alerted on. Most real-time fleets alert on resource utilisation, which is the number that looks calm while a hardware encoder runs out of sessions — the ceiling is a count, not a load. The first thing this does is establish which counters actually bind on your system, and re-point the alerts at those. Frequently that means fewer alerts, not more.

Both, because on an always-on system they are the same failure. A stream that silently falls back from hardware to software encoding keeps working while its CPU cost multiplies, so the first evidence is an invoice rather than an incident. Cost per minute is tracked as a first-class metric next to latency and capacity.

That is the intended end state and the deliverables are built for it: the counters, the derived limits and the runbook are yours, documented, from the first month. We would rather be the people whose monitoring your team kept than the people they had to keep to understand it.

// Related

All services

// Industries

Where teams put this to work:

15+systems shipped
6+ yrsin production
~4 wksto a first slice
99.9%uptime SLA

// Let's build

Ready to build with real-time ops?

Tell us where you are. We reply within a day with a concrete next step.