Products Communications-quality observability and operational intelligence

Beacon

A small agent at the customer site that continuously measures the conditions affecting communications quality and reports them back for visibility and investigation. Built to answer "was it the network?" with evidence instead of opinion.

In active development.

See the dashboard

How it works

Measure where the problem is, not where the tools are.

Most monitoring watches the middle of the network. The experience that people complain about happens at the edge of it — in one office, on one link, at one time of day.

A Beacon agent runs at the customer location and takes local measurements. Telemetry is sent outbound to ddash™, where it is stored, analyzed and correlated across sites. Trends and degradation detection surface developing problems. Both RPR and the customer see the same picture, which supports investigation and corrective action.

Beacon reports what it can measure from its vantage point. Where an environment does not support deriving a particular indicator, it reports the underlying measures rather than estimating one.

Demo

A degradation, as Beacon would show it.

Four sites, one of them degrading. Latency, jitter and loss are drawn as three separate panels with their own scales — plotting measures with different units on one axis makes a chart look decisive and read wrong.

Beacon — sandbox tenant Demo · Fabricated telemetry

Sites reporting

  • Degraded Harbour Road — main office MOS 3.6 RTT 94 ms Loss 3.1% Upstream congestion
  • Healthy Kiln Street — fabrication MOS 4.3 RTT 31 ms Loss 0.0% Nominal
  • Healthy Fenwick Depot MOS 4.2 RTT 44 ms Loss 0.1% Nominal
  • No data Alder Yard — remote MOS RTT Loss No agent check-in for 14 min

Harbour Road · last 2 hours

Round-trip latency 37ms

36ms peak 121ms 121ms

Jitter 4ms

3ms peak 38ms 38ms

Packet loss 0%

0% peak 4.2% 4.2%

Degradation timeline

  1. 14:05 Latency and jitter rising at Harbour Road
  2. 14:20 Packet loss crossed threshold — degradation opened
  3. 14:35 Path change detected on upstream hop 3
  4. 15:10 Metrics returning to baseline
A two-hour window at a fictional multi-site business, showing an upstream congestion event building and clearing. All sites, measurements, timings and events on this screen are invented for demonstration. No customer site, address, tenant, IP or real measurement is represented. The live dashboard is not connected yet — this is the shell it will run in.

What it measures

Nine measurement categories.

What any given deployment reports depends on what the environment supports. We would rather tell you a measure is unavailable at your site than show you a number we inferred.

Latency

Round-trip time to the endpoints that matter, sampled continuously rather than when someone complains.

Jitter

Variation between packet arrivals — usually the first thing to move when a call starts sounding wrong.

Packet loss

What proportion of traffic never arrives, measured on the path that actually carries the calls.

Availability

Whether the connection and the endpoints are reachable, and for how long they were not.

Connectivity

Reachability of the services the site depends on, distinguishing a local fault from an upstream one.

DNS behavior

Resolution success and response time, which quietly breaks more sessions than people expect.

Path quality

Where the traffic goes and where it degrades — the hop that changed, not just that something did.

Historical trends

The same measures over weeks, so a gradual degradation is visible before it becomes an outage.

Voice quality indicators

MOS and related indicators where the environment supports deriving them. Where it does not, Beacon reports the underlying measures rather than estimating a score.

How it is built

Deliberately small.

Lightweight by design

A small agent with a narrow job, not a management platform that needs its own project to deploy. It measures, it reports, and it stays out of the way.

Outbound only

Telemetry leaves the site over an outbound connection. No inbound firewall rules, no exposed listener, no new attack surface at the customer edge.

Measures from where it hurts

Testing from a datacenter tells you the datacenter is fine. Beacon measures from the office where the calls are actually breaking up.

Evidence, not opinion

When the answer is "it is not our network," Beacon is what lets you demonstrate that — with a timeline you can hand to whoever owns the link.

What changes operationally.

No uptime percentages or resolution-time figures appear here. Beacon is in active development and we have not measured those across enough deployments to publish one.

A quality complaint arrives hours after the problem, with nothing to look at.
The window is already recorded, with the measures that moved.
Diagnosis means running a test now and hoping the fault reappears.
The history shows whether this is new, recurring, or slowly worsening.
Fault ownership is argued rather than established.
Path and timing evidence points at the segment that actually degraded.
Each site is investigated in isolation.
Sites are compared, so a shared upstream cause becomes obvious.

Start with the customer journey

Put a Beacon where the complaints come from.

If you have a site with a recurring quality problem nobody has been able to pin down, that is the one we would want to measure first.