Zoom Workplace extension

• Latest Dynatrace
• Extension
• Published Aug 20, 2026

Coming soon

Monitor Zoom Workplace meeting quality, availability, and user license capacity by ingesting metrics and structured logs from the Zoom REST API into Dynatrace.

Get started

Overview

The extension polls five Zoom REST API v2 endpoints and, per collection cycle:

The five endpoints it calls:

The meeting QoS call is also made (independently of those three feature sets) whenever the meeting & participant activity logs option is on.

Five endpoints, but more than five calls per cycle: GET /users is issued three times (once each for active, inactive, and pending, because Zoom does not accept status=All), GET /phone/devices twice (assigned and unassigned), and the QoS endpoint once per live meeting. Every page of a paginated response counts as a separate call as well.

Use cases

Requirements

Only the meeting-overview scope is validated at activation time. The other four degrade at runtime. If a scope is missing, that endpoint returns 403, the extension logs it and reports a non-OK endpoint status for that feature set, and the rest of the collection keeps working.

Compatibility information

This extension works with the Zoom REST API v2 and delivers complete, out-of-the-box observability for the following Zoom data groups:

For these data groups, everything is ready to use from the moment a monitoring configuration is saved. Metrics, dashboards, alerts, and Smartscape topology are all populated for you.

Which data groups reach Dynatrace is determined by the feature sets you enable and the OAuth scopes you grant, not by the extension, so you always stay in control of what you collect and what it costs in Zoom API calls.

This extension also has the following constraints:

Activation and setup

Activation has four parts. Activate the extension from Dynatrace Hub, create the Zoom OAuth app, create the monitoring configuration, and verify that data is flowing. The prerequisites are listed under Requirements.

Details

The Zoom Workplace extension collects metrics and topology for:

Metrics are reported under the zoom.* namespace and collected from the following feature sets (enable them per monitoring configuration during activation). The default feature set is always on and reports active meetings, per-meeting participant counts, and average meeting duration:

The extension is packaged with four dashboards, two Live pages (Rooms, and Users & Phone Devices) and two Trends pages (Meeting Quality, and API Monitoring), that serve as a starting point for data analysis, and with seven alert templates that ship inactive and can be enabled from the extension's Content page.

Rate limiting and error handling

Zoom enforces API rate limits at the account level, shared by every OAuth app and integration connected to that account, not per API key and not per app. The extension therefore paces itself proactively rather than waiting to be rejected.

Pacing

A single token-bucket registry is shared by every collector and every QoS worker thread, so it tracks the total request rate across the extension. It is sized for Zoom's Pro plan and deliberately runs at 80% of each published ceiling to leave margin for network timing:

Resource-intensive is the strictest of the four, because it is a per-minute limit rather than a per-second one. Zoom also applies a daily cap shared between the Heavy and Resource-intensive classes (30,000 requests/day on Pro). That cap is not paced proactively, but handled reactively when Zoom reports it.

Handling active rate limits

When Zoom rate-limits anyway (because something else on the account is also making requests), the extension reads the X-RateLimit-Type header and reacts accordingly:

Failure handling

Every collector treats a failed endpoint as a skipped cycle rather than a crash. It logs the failure with a DEC: code, reports the appropriate endpoint status, and lets the next scheduled cycle try again.

Pagination

All five endpoints are cursor-paginated via next_page_token, which expires after 15 minutes. If a cycle's pagination exceeds that window, the extension restarts once from page 1. A restart that also exceeds it is reported as an error. Page sizes are 300 for meetings, rooms, users, and phone devices, and 10 for the QoS endpoint (Zoom's maximum).

QoS fan-out

Because Zoom exposes no bulk multi-meeting QoS call, each live meeting is fetched individually. A bounded pool of 8 workers drains this queue, paced against the shared Heavy bucket, and each meeting's results are reported and released as its fetch completes, so a large account's full QoS payload is never held in memory at once.

Which QoS sample is reported

Zoom returns user_qos in ascending time order, and the last element is the current, possibly still-incomplete minute. The extension reports the second-to-last element (the most recent fully elapsed minute) and stamps the metric at that sample's own timestamp rather than at collection wall-clock. A participant with fewer than two samples is skipped, and individual blank or unparseable QoS fields are skipped rather than reported as false zeros.

Smartscape on Grail

The extension models its estate twice, and both models are installed automatically.

Classic topology

Declared in extension.yaml and built directly from metric dimensions:

Both zoom:room and zoom:phone_device are related to zoom:account with a PART_OF relationship, mirroring how Zoom organizes its estate.

Smartscape 2.0

Built by the bundled Zoom Smartscape Metrics Pipeline, which extracts nodes and edges from the zoom.* metrics as they arrive, so the map stays live rather than static:

Each Zoom Room and Zoom Phone Device node carries an is_part_of static edge to its Zoom Account node. Every zoom.* metric is also stamped with the Zoom Account node ID, and the room metrics (zoom.rooms, zoom.room.component.status) with the Zoom Room node ID, so metrics attach to the right node.

The account node is upserted from zoom.meetings.active, which belongs to the always-on default feature set, so the account node exists as long as the extension is reporting at all. Room and phone device nodes require their respective feature sets to be enabled.

To explore the topology, open the Smartscape app and filter for Zoom Account, Zoom Room, or Zoom Phone Device, then select an entity to walk its connections. Allow a few minutes after the first collection cycle.

Licensing and costs

There is no charge to use the extension. You are only charged for the data that the extension ingests.

The Zoom Workplace extension ingests metrics and structured logs. The extracted metrics consume Davis Data Units (DDUs) (Dynatrace classic license) or Metrics powered by Grail (DPS), according to your license model.

Dynatrace Platform Subscription

In the Dynatrace Platform Subscription, metric ingestion consumes Metrics powered by Grail according to the number of ingested metric data points.

The following formula provides approximate data points ingested per minute, assuming all feature sets are enabled and the default collection intervals.

(
    (  3 unique meeting metrics       * dimension combinations )   -- default (always on)
  + (  5 unique audio QoS metrics     * dimension combinations )   -- meeting_audio_qos
  + (  5 unique video QoS metrics     * dimension combinations )   -- meeting_video_qos
  + (  3 unique CPU metrics           * dimension combinations )   -- participant_cpu_usage
  + (  3 unique Zoom Room metrics     * dimension combinations )   -- zoom_room_health
  + (  1 unique user metric           * dimension combinations )   -- user_license_capacity     (every 5 min)
  + (  1 unique phone device metric   * dimension combinations )   -- phone_device_status       (every 5 min)
  + (  3 unique self-monitoring metrics * dimension combinations ) -- self_monitoring
) * 60 minutes * 24 hours * 365 days data points per year

A "dimension combination" is a distinct set of values across a metric's dimensions. Omit any line for a feature set you don't enable.

In practice, each combination maps onto one real object (a meeting, participant, Zoom Room, user, or phone device) because every metric carries an identity dimension (meeting_id, participant_id, room_id, user_id, device_id). Only two dimensions multiply that count, direction (input/output) on the QoS metrics and component (six values) on zoom.room.component.status. So cost scales with the size of your live Zoom estate and how often you poll it, not with the number of metric keys or dimensions.

For the activity logs, regular consumption applies. See Log Analytics. Activity logs add one record per live meeting, one per participant with a QoS sample, and one per open Zoom Room issue, per real-time cycle.

Dynatrace classic license

In the classic licensing model, metric ingestion consumes Davis Data Units (DDUs) at the rate of .001 DDUs per metric data point. Multiply the above formula for annual data points by .001 to estimate annual DDU usage.

For the activity logs, regular consumption applies. See DDU consumption for Log Management and Analytics or DDUs for Log Monitoring Classic. Activity logs add one record per live meeting, one per participant with a QoS sample, and one per open Zoom Room issue, per real-time cycle.

DDUs consumed by this extension are eligible for the free tier included with every host.

DQL and logs

Beyond metrics, the extension sends three structured log streams to Grail. Logs carry the per-meeting, per-participant, and per-room-issue detail that would otherwise explode metric cardinality, and they stay queryable with DQL.

Every record carries timestamp, log.source, event.type, content, dt.extension.name, and dt.extension.config.id, plus the fields below. zoom.meeting.activity and zoom.participant.activity records are flushed to the platform in batches of 1000 rather than accumulated for a whole cycle, so the log buffer never scales with the account's meeting × participant count. zoom.room.issue records are flushed once, at the end of the Zoom Room poll.

zoom.meeting.activity

event.type is meeting_sample.

zoom.participant.activity

event.type is participant_qos_sample.

zoom.room.issue

event.type is room_issue.

Personally identifiable information

The activity logs deliberately exclude PII. user_name, email, ip_address, mac_addr, and pc_name are never written to zoom.participant.activity, and the meeting record carries the host's department and license type but not their name or email. Note that this is a property of the logs. The QoS metrics do carry a participant_name dimension, and zoom.meetings.participants carries a host dimension, because the dashboards and alerts identify who is affected.

The Live Rooms dashboard's Recent Room Issues tile reads zoom.room.issue directly. The other two streams are available for ad-hoc DQL in Notebooks.

FAQ