Screen recording observability

Screen recording observability is a set of telemetry entries reporting whether Amazon Connect screen recording ran for each contact. The Agent Collector watches the Contact Control Panel (CCP) log stream, picks out the screen recording lifecycle lines, and ships them as structured entries tagged ScreenRecording. This page is for anyone who has to evidence screen recording coverage. The job is to find which contacts recorded, which didn’t, and which agents account for the difference.

What Amazon Connect reports

Amazon Connect reports that a contact was flagged for screen recording. Operata reports what happened next: whether the agent’s machine recorded it, and whether the recording reached S3. The failure sits on the agent endpoint. Screen recording depends on the Amazon Connect client app — a Windows installer that endpoint management has to deploy to every agent workstation. When the app is missing, blocked, or broken, Amazon Connect still flags the contact, the CCP still creates a recording, and nothing uploads. The Contact Trace Record (CTR) carries the flag, not the outcome. Screen recording often carries a contractual compliance obligation, and the evidence for it is the gap between those two facts.

Before you start

Screen recording telemetry is off by default. Three things have to be true:

Operata enables it on your group. The Agent Collector reads a screenRecordingTelemetry flag from the collector configuration Operata serves to each group. When the flag is absent, the Collector defaults it to false and skips screen recording parsing entirely. Ask Operata support to turn it on.
CCP log collection is on. The parser runs inside the CCP log pipeline. No log collection, no screen recording telemetry.
Agent Collector v1.7.29 or later, on Chrome or Microsoft Edge, with agents on Windows. The Amazon Connect client app ships as a Windows MSI, so macOS agents produce no screen recording.

Screen recording telemetry is Amazon Connect only. The Genesys Cloud and NICE CXOne adaptors don’t emit it.

How it works

The Agent Collector hooks the Amazon Connect Streams logger in the agent’s browser. For every captured entry at INFO level whose text mentions recording, it runs the screen recording parser. Two component names show up in the logs, so check which one you’re filtering on:

screenRecorder — Amazon’s component on the raw CCP log lines the screen recorder writes. These are in the CCP logs whether or not screen recording telemetry is on. Filter on component = screenRecorder to read them, including the WARN and ERROR lines.
ScreenRecording — Operata’s component on the telemetry entries the parser creates. These only exist when screen recording telemetry is enabled on your group.

The parser matches five lifecycle patterns and turns each into a telemetry entry with component: "ScreenRecording":

Log line contains	Entry `text`	Captured in `data`
`New recording`	`New recording`	`contactId`, `screenRecordingEnabled`, `screenRecordingId`
`PUT S3Upload for recording`	`PUT S3Upload for recording`	`blockNumber`, `blockStatus`, `contactId`
`Detected ended contact` (with a JSON payload)	`Detected ended contact - recording end contact object`	The contact summary object
`Detected ended contact` (with a JSON payload)	`Detected ended contact - recording end task objects`	`recordingTaskObjs`, `contactId`
`Received CCP ContactRefreshed event for contact`, or `TAPS.RECORDING.SIGNAL`	The raw log line	`contactId`

Each entry joins the CCP log stream the Collector already ships, carrying the contact ID, a timestamp, and the standard vendor fields. Operata builds the per-contact screen recording summary server-side from those entries.

Amazon Connect flags contact for screen recording
  → CCP creates a recording, client app uploads parts
  → Streams logs each transition at INFO
  → Agent Collector parses matching lines
  → ScreenRecording telemetry entries in the CCP log stream
  → Operata assembles the per-contact summary

The parser reads INFO entries only, so screen recording warnings and errors stay ordinary CCP log lines rather than becoming ScreenRecording telemetry. The lifecycle payloads come from Amazon’s log text, so their shape follows the Streams library, not an Operata contract.

What’s collected

Recording start

Emitted when the CCP creates a recording.

Name	Type	Description	Example
`contactId`	string (UUID)	The contact the recording belongs to.	`04ea96b3-454f-4f65-9767-784e2e99b694`
`screenRecordingEnabled`	boolean	Always `true` on this entry — its presence is the signal that recording started.	`true`
`screenRecordingId`	string (UUID)	The recording the CCP created.	`69ee35e5-faf5-425c-a727-8a15cd151fe9`

Part upload

Emitted once per block the client app pushes to S3. Counting these entries tells you how much of the recording left the workstation.

Name	Type	Description	Example
`blockNumber`	integer	The block this upload covers.	`1`
`blockStatus`	string	Upload outcome as reported in the log line.	`SUCCESS`
`contactId`	string (UUID)	The contact being recorded.	`04ea96b3-454f-4f65-9767-784e2e99b694`

End of contact

When the contact ends, the CCP logs a summary the parser splits into two entries: the contact object, and the array of recording task objects. Contact object:

Name	Type	Description
`agentId`	string (UUID)	The Amazon Connect agent handling the contact.
`contactId`	string (UUID)	The contact the recordings belong to.
`initialContactId`	string (UUID)	The first contact in the chain. Differs after a transfer.
`contactState`	string	Contact state at assembly, such as `ENDED`.
`contactType`	string	Channel of the contact, such as `VOICE`.
`contactStartTimeMillis`	integer (epoch ms)	When the contact started.
`contactEndTimeMillis`	integer (epoch ms)	When the contact ended.
`contactLastKnownTimeMillis`	integer (epoch ms)	Last contact state the CCP observed.
`recordingTasks`	array of string (UUID)	Recording task IDs for this contact. An empty array means the CCP created none.

Each entry in recordingTaskObjs:

Name	Type	Description
`recordingId`	string (UUID)	The recording task. Matches an ID in `recordingTasks`.
`recordingStatus`	string	Terminal state of the recording, such as `SUCCEEDED` or `FAILED`.
`recordingStartTimeMillis`	integer (epoch ms)	When capture started.
`recordingEndTimeMillis`	integer (epoch ms)	When capture stopped.
`recordingLastKnownTimeMillis`	integer (epoch ms)	Last recording state the CCP observed. Runs past `recordingEndTimeMillis` while final parts upload.
`totalRecordingBlocks`	integer	Blocks the client app captured.
`totalSizeInBytes`	integer	Total captured size.
`numOfPartsUploaded`	integer	Parts the client app uploaded. Compare against `totalRecordingBlocks`.
`latestPartNumReceived`	integer	Highest part number the service acknowledged.
`isLastPartReceived`	integer	`1` once the final part is acknowledged, `0` until then.

The Collector passes these through from Amazon’s payload without transforming them. Treat the Amazon Connect documentation as the authority on their exact semantics.

Reading the result

Compliance reporting asks three questions of each contact.

Question	Where to look	Healthy
Did recording start?	A `New recording` entry for the contact	Present, with a `screenRecordingId`
Did parts upload?	`PUT S3Upload for recording` entries	One per block, each with a successful `blockStatus`
Did it complete?	`recordingStatus` in `recordingTaskObjs`, plus `numOfPartsUploaded` against `totalRecordingBlocks` and `isLastPartReceived`	`SUCCEEDED`, counts match, `isLastPartReceived` is `1`

The case to chase is a contact with a New recording entry and no upload entries behind it. Recording started and produced nothing.

Failure signatures

Recording started, nothing uploaded. A New recording entry, then an end-of-contact entry, with no PUT S3Upload for recording entries between them. The Amazon Connect client app is missing, not running, or blocked on that workstation. This is the most common cause, and it usually points at an endpoint deployment problem across the estate rather than a per-agent fault. Recording never started. The contact was flagged in Amazon Connect, but no New recording entry exists and recordingTasks comes back empty in the end-of-contact object. Partial upload. Upload entries exist but stop short — numOfPartsUploaded trails totalRecordingBlocks, or isLastPartReceived stays 0. The workstation lost the network or the app died mid-contact. Amazon also logs screen recording problems at WARN and ERROR — stale recording state, recordings marked FAILED, contacts dropped for having no recording task. Those lines are not captured as ScreenRecording telemetry, because the parser only reads INFO entries. They do appear in the raw CCP logs under component = screenRecorder when your capture level includes them. Pull the full log for the agent and time range from Calls and logs and read it with the CCP log parser.

Privacy

Operata reads screen recording metadata out of CCP log text. It does not access the recordings themselves — no video, no frames, no screen content, and no access to the S3 bucket the recordings land in. Every field above is parsed from a log line. The Collector has no media path and no S3 credentials.

Limits

Collection works today. The reporting layer on top of it is still being built.

Off by default. Screen recording telemetry needs Operata to enable the flag on your group. It is not automatic on upgrade.
No packaged coverage dashboard. Operata does not yet ship a screen recording coverage report or a “recording failed” insight. Reach the data through CCP logs and custom dashboards. The packaged report — flagged, recorded, and transmitted as contact attributes visible in Canvas — is on the roadmap.
Not in the MCP trace schema. The Operata MCP Server exposes the underlying softphone logs through agent_logs and traces_span_logs, so an AI client can read the raw lifecycle entries. The normalized screen recording summary is not yet part of the CX trace schema, so you can’t query it as a structured field.
Warnings and errors aren’t tagged. The parser reads INFO entries only, so Amazon’s screen recording WARN and ERROR lines stay in the raw log stream rather than becoming screen recording telemetry.
Retention on the summary data differs from log retention. Confirm the current window with Operata support before you build a reporting process on it.
Operata can’t see whether the client app is installed. It observes what the CCP logs. A missing client app is an inference from the failure pattern, not a direct reading.
Payload shape follows Amazon. The end-of-contact fields come from the Streams log text and can change when AWS changes the library.

Agent Collector — the browser-side collector that captures this data.
CCP error logs — the other log stream the Collector attaches to each contact.
Tools and logs — getting raw logs out of Operata.
Data collection — Amazon Connect — the full collection picture for Amazon Connect.
Amazon Connect screen recording — AWS requirements and setup.

​What Amazon Connect reports

​Before you start

​How it works

​What’s collected

​Recording start

​Part upload

​End of contact

​Reading the result

​Failure signatures

​Privacy

​Limits

​Related