Extending SmartBlock Probe Expiry

Glean probes have an expiry version. When that version arrives in release, the probe stops collecting and any dashboards built on it go silent. This patch pushed several SmartBlock probes out to Firefox 160.

Bug 2026447 | D291234 | Reviewer: manuel

The Problem

Glean (Mozilla’s telemetry framework) requires every probe to declare an expiry. The expiry is a Firefox version number. Once that version is in release and probes have rolled off the supported channels, the data stops flowing. The expiry exists for good reasons: telemetry that no one uses anymore is just noise (and a privacy cost), so probes are forced to renew themselves periodically by an explicit human action.

The downside is that probes can quietly expire while the team that depends on them is still actively using the data. SmartBlock had a handful of probes in this state — they’d been set with an expiry that was getting close, the team was still using them on dashboards, and nobody had pushed the expiry out.

The Fix

Two-line patch per probe in metrics.yaml. Bump expires to 160 (next-next major). That’s it.

The reason this kind of patch is worth writing about isn’t the code. It’s the operational discipline.

The Operational Lesson

Telemetry probes are infrastructure. They have lifecycles. If you build a dashboard on top of them, someone needs to own:

  • Knowing when they expire
  • Knowing whether the data is still being used
  • Renewing them in time, or sunsetting the dashboards built on them

Without that ownership, you eventually find out a dashboard is broken because the probe expired six months ago and nobody noticed. Bumping expiries is a small task; making sure someone is doing it on a schedule is the real work.

What I Learned

  1. Expiry is a feature, not friction. Forcing probes to renew prevents the slow accumulation of stale telemetry. The friction of bumping expiries is the system working as designed.

  2. Two-line patches still need a clear “why.” The commit message and Bugzilla discussion need to explain why this probe is still useful, not just bump it. A reviewer who doesn’t see the justification has no way to evaluate the request.

  3. Probe ownership is fuzzier than code ownership. A probe might be defined in a YAML file that lives in one module’s directory, but the dashboards that consume it can be owned by a totally different team. That mismatch is where these patches come from.