/recording-coverage

name: "Dubber Recording Coverage Audit"
description: >
  Read-only audit that proves Dubber is actually capturing calls for a
  client: which Dub.Points (recorded lines) have recent recordings and which
  have gone silent, recordings Dubber could not match to an account, and
  whether REST-hook integrations are active and draining. Covers the tool
  sequence, the thresholds for flagging a line, and how to report gaps
  honestly when a list may be truncated.
when_to_use: >-
  When an MSP needs to confirm call recording is working for a client, before
  a compliance review, after a phone-system change, or when a client says a
  call "wasn't recorded". Use when: recording coverage, are calls being
  recorded, silent dub point, missing recordings, unidentified recordings,
  dubber health check, call recording compliance audit, webhook backlog.

Dubber Recording Coverage Audit

Overview

A recorded line can stop capturing without anyone noticing: a phone-system change, a re-provisioned handset, or a Dub.Point left inactive. For clients with a recording obligation (financial advice, healthcare, collections) a silent line is a compliance gap. This audit checks each Dub.Point for recent recordings and looks for calls Dubber captured but could not place. Every tool used here is read tier in Conduit.

Anti-triggers

• **Finding specific calls for a dispute or QA review** — use `dubber-call-retrieval`.
• **Adding or removing Dubber users** — use `dubber-user-lifecycle`.

Inputs

• Account ID (required; there is no tool that lists all accounts).
• Group ID (optional; needed for the unidentified-recordings check).
• Look-back window. Default: the last 7 days. Use the client's local offset.
• Which lines are expected to record. Ask the user if they have a list; otherwise treat

every Dub.Point with an active status as expected.

Workflow

1. **Confirm the connection.** `dubber_test_connection`. If it fails, stop and report the credential or region problem (see `dubber-api-patterns`). 2. **Confirm the account.** `dubber_accounts_get` with the account ID. Note the account name and timezone for the report. 3. **List the recorded lines.** `dubber_dub_points_list`. For each Dub.Point record its `id`, `name`/`label`, `status`, `external_type`, `external_identifier` and owning `user` (the user ID is the last segment of the URL). If exactly 20 come back, the list may be truncated; say so in the report. 4. **Check each line for recent calls.** For each Dub.Point call `dubber_recordings_list` with `dubPointId`, `startTimeFrom` set to the start of the window, and `limit: 1`. One returned recording is enough to prove capture. Then note its `start_time` as "last seen". An empty result means "silent" only when the scan finished: if `scanCapReached` or `hasMore` is true, call again with `cursor=<nextCursor>` and `offset=<remainingOffset>`. If `excludedUnparseableStartTime` is above 0, mark the line "unknown" rather than silent. 5. **Date the silent lines.** For a Dub.Point with no recording in the window, call `dubber_recordings_list` with `accountId`, `dubPointId` and `limit: 1` and no time filter to find the most recent call it ever recorded. No result at all means the line has never recorded. 6. **Look for unmatched calls.** If you have the group ID, call `dubber_groups_list_unidentified_recordings`. A growing pile here usually means a line is recording but is not mapped to a Dub.Point, which is the other half of a "missing recording" complaint. 7. **Check integrations.** `dubber_notifications_list`. For each subscription, note `event`, `url` and `active`. For active ones, call `dubber_notifications_list_unclaimed`; a non-empty backlog means the receiving system (PSA, CRM, archive) is not taking events.

Flagging rules

| Finding | Severity | |---|---| | Expected line with no recording in the window and none ever | High: never captured | | Expected line silent for the whole window but recorded before it | High: capture stopped; give the last-seen date | | Unidentified recordings present on the group | Medium: mapping gap | | Dub.Point status not active | Medium: confirm whether intentional | | Inactive subscription, or active one with unclaimed events | Medium: integration broken | | Line silent but the user is known to be on leave or the line is a spare | Info: note and move on |

A quiet line is not always broken. Weekend-only windows, part-time staff and fax or alarm lines produce false positives. Ask before escalating a single quiet line.

Report

Per account: account name, window, then a table of Dub.Points with name, external identifier, user, status, recordings-in-window (yes or no) and last-seen date. Follow with unidentified-recording count, integration status, and a short list of actions. State any truncated list and any Dub.Point whose scan hit `scanCapReached`.

Gotchas

• Use `limit: 1` for the presence check. Scanning a busy line's whole week costs up to

25 Dubber requests per call against a 500-calls-per-day token budget.

• `start_time` without an offset is read as UTC. A "Monday" window in Sydney or London

needs the right offset or it shifts by hours.

• This audit does not change anything. Fixing a silent line usually happens in the phone

system or the Dubber portal, not through these tools.