WEBRTC_CALL_DURATION was unfortunately defined with 1000 buckets—most histograms cap out at 100—which I believe is why it doesn't render as a in the [measurement dashboard](https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-04-29&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F76&measure=WEBRTC_CALL_DURATION&min_channel_version=beta%252F65&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2020-04-06&table=0&trim=1&use_submission_date=0), even though it is still recorded, as you can tell from the 426.26k Ping Count. We know the data is there, even in release, as we've done sql queries on it like [this one](https://sql.telemetry.mozilla.org/queries/71939/#180528) (a graph that for full disclosure is incorrect since it discounts non-webrtc users, but is still pretty and shows an uptick in usage during COVID-19 among active WebRTC users). I hadn't tried it in the about:telemetry dashboard before, but perhaps it suffers from the same problem? Would love to see this fixed. Tossing over to Telemetry folks, as I suspect this is a data display problem.
Bug 1654248 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
WEBRTC_CALL_DURATION was unfortunately defined with 1000 buckets—most histograms cap out at 100—which I believe is why it doesn't render as a histogram in the [measurement dashboard](https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-04-29&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F76&measure=WEBRTC_CALL_DURATION&min_channel_version=beta%252F65&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2020-04-06&table=0&trim=1&use_submission_date=0), even though it is still recorded, as you can tell from the 426.26k Ping Count. We know the data is there, even in release, as we've done sql queries on it like [this one](https://sql.telemetry.mozilla.org/queries/71939/#180528) (a graph that for full disclosure is incorrect since it discounts non-webrtc users, but is still pretty and shows an uptick in usage during COVID-19 among active WebRTC users). I hadn't tried it in the about:telemetry dashboard before, but perhaps it suffers from the same problem? Would love to see this fixed. Tossing over to Telemetry folks, as I suspect this is a data display problem.