REPLAY → LENS
Investigate with Replay and Lens
Use Replay to review the sequence of recorded service changes. Open Lens when you need the source evidence behind a selected event.
Replay: understand what changed, and when
An alarm appeared, a worker restarted, or a request failed while the services kept running. Return to the saved recording and inspect the observations before and after the event.
- Select a recording date and interval.
- Play, pause, scrub or step through retained observations.
- Compare state changes with application events and visible recording gaps.
Lens: inspect the record behind the event
A timeline tells you when something was recorded. Lens lets you read the selected source message, distinguish source time from CTK recording time, and inspect retained records with the same trace or request ID.
- Read the source message and available structured fields.
- Follow matching trace or request IDs in retained evidence.
- Check what the source actually reports before deciding on a fix.
Actual CTK screens from a controlled local Docker demo. The failed checkout and matching payment record are demo data, not customer records.
From an alarm to the evidence
- 01
Start a watch
Connect your repository or a supported cloud target and start watching. For application events, enable Application evidence in Observe → Configure sources and explicitly select the sources available for that connector.
- 02
Open the investigation
From Alarms or Activity, select the event you want to investigate. Open Replay, or Open recording on an application-evidence record, to inspect the retained recording.
- 03
Review the sequence in Replay
Choose the relevant date and interval. Move backward or forward, use Play to advance through recorded points, and select the change or application event you want to inspect.
- 04
Open the evidence in Lens
Use Open in Lens for a selected observation, or Inspect evidence for an application record. Read the source details and any retained records with matching trace or request IDs. Make and verify your own fix outside CTK.
CONTROLLED DEMO
Example: checkout fails while health checks pass
In this demo, orders-api records a failed checkout and payments-api records a rejected authorization. Lens shows the two retained messages with the same trace or request ID. This gives the developer a concrete lead to investigate even when the service health checks are passing.
Know what the recording covers
- Replay plays saved observations. It does not rerun requests, restart services or reproduce a failure in your environment.
- CTK must be running with an active watch to collect new observations. On macOS, enabling background watching keeps watches active when the window closes. Quitting CTK, sleep, failed reads and stopped watches can leave gaps; Replay displays coverage boundaries.
- Recordings and application evidence have bounded local retention. Events before collection, between polls, or outside retained data cannot be reconstructed. A previous Activity entry may have no retained recording.
- Application evidence depends on the connector and explicitly selected sources. Azure currently supplies resource Activity Log events, not application-request diagnostics. CTK does not automatically instrument your code.
- A shared ID links records; it does not establish root cause. A nearby event or a later healthy reading alone does not prove what caused or fixed the failure.
Replay and Lens questions
When should I use Replay instead of Lens?
Use Replay to review the order of retained observations around an incident. Use Lens to inspect the source evidence for one selected observation or application event. The two views complement each other.
What happens when I press Play in Replay?
The cursor advances through saved recording points and the selected details update. CTK does not execute the application, repeat requests or change the watched services.
Can Replay recover events from when CTK was not running?
No. Replay uses retained observations collected by CTK. Observation gaps remain visible. Some selected log sources can supply a bounded backfill, but that is not a complete reconstruction of an unobserved interval.
Does Lens automatically find the root cause?
No. Lens exposes source messages, timestamps, available fields and retained records with matching trace or request IDs. The developer evaluates that evidence; a matching ID or temporal proximity is not proof of causality.
Are Replay recordings and raw application evidence shared through MCP?
No. Recordings and application evidence stay in the local workspace. Existing CTK MCP permissions do not expose Replay journals or the new raw application-evidence payloads and correlation IDs.
Replay → Lens
Go back to the event. Look closer at the evidence.
Use Replay to review the sequence of recorded service changes. Open Lens when you need the source evidence behind a selected event.