REAL CTK WALKTHROUGH
From a Docker memory failure to a healthy worker.
A worker stops while the rest of the project keeps running. This controlled local demo follows the affected service, the runtime’s explanation, and the developer’s source change—not an automatically generated fix.
Controlled local demo · No customer data · 1:13 min
01
Start with the running project
Connect the local orders-engine repository and choose Watch with Docker. CTK reads the existing workload; starting this watch does not launch Docker Compose.
The initial view contains eight services and no incident. That baseline matters: it lets the developer see which service changes when the controlled failure occurs.
02
Separate the observed stop from its reported cause
The order-worker container runs out of memory. CTK identifies the affected worker while the other services remain running. Open Alarms, select its alarm, and inspect the worker’s reading in Observe.
The source-reported reason says the container ran out of memory. This is more specific than a failed health check, which alone would not establish an out-of-memory cause. A log line or an unhealthy mark is not a substitute for that evidence.
03
Make the source change as the developer
In this demo, the worker batches 32 records, each carrying an 8 MiB payload. The developer inspects the actual source, changes BATCH_SIZE from 32 to 2, and saves the file.
The smaller batch is a change to this particular workload, not a universal prescription for memory failures. CTK exposes the runtime record; the developer decides what to change and makes the edit outside CTK.
04
Check the state after the intervention
After the worker restart, return to Overview. The recorded walkthrough shows the worker running again, passing health checks and no current incident.
That confirms the recovered service state shown in CTK. It does not, on its own, prove that every business operation completed or that a memory problem can never recur. Verification should match the question being asked.
What this demo does—and does not—prove
Real application footage from a controlled local test, not a customer production incident. This edit shows the source change and the recovered CTK state; the restart command and a 32/32 job-output verification are not shown. CTK does not automatically edit source code or guarantee a root cause when the source has not reported one.
Read the on-screen text
- 0:00
Start with a local repository.
- 0:04
orders-engine is connected. Open the repository.
- 0:10
Start watching the Docker services.
- 0:14
CTK begins reading the local runtime.
- 0:19
Eight services. No incident.
- 0:23
A controlled memory failure stops order-worker.
- 0:27
CTK identifies the affected worker.
- 0:31
Open Alarms for the runtime evidence.
- 0:34
Open the order-worker alarm.
- 0:36
CTK takes us to that worker’s runtime reading.
- 0:40
Why: the container ran out of memory.
- 0:43
Next, inspect the worker’s source code.
- 0:47
This demo worker batches 32 records, each with an 8 MiB payload.
- 0:51
Reduce BATCH_SIZE from 32 to 2.
- 0:54
Save the source change.
- 0:57
After the worker restart, return to CTK.
- 1:00
Open Overview to check the current service state.
- 1:03
No incident. Health checks are passing.
- 1:06
order-worker is running again.