Investigate a service incident with CTK

01

1. Establish the current scope

Open the affected watched repository from Home. In Overview, identify the service that needs attention, then open Observe for the full reading. Check freshness before treating a retained snapshot as current.

Read What, When, Why and How together. An out-of-memory report, an exit code and an unhealthy check are different facts. No cause recorded means the source did not state one; it is not an invitation to invent an explanation.

02

2. Separate a failure from a missing observation

Use Signals to inspect which runtime and health readings are present. Normalize helps show whether both sides were combined or one side is missing. A running process with no health check has less evidence than a service with a passing check.

Insights and Inference organize the same available evidence. They do not create a new measurement or make an unobserved dependency become established. Return to Observe whenever you need the source-stated cause.

03

3. Reconstruct the recorded sequence

Open Timeline and compare the affected service before, during and after the incident. Use Activity to inspect changes across watched repositories. Note both the service and the time instead of treating nearby events as a proven chain of causation.

The local history retains the latest 1,000 recorded changes per repository. It is a change history, not an unlimited raw-log archive or a continuous recording of every event between polling intervals.

04

4. Check current alarms and dependencies

Alarms surfaces currently stated causes; it is not the complete historical incident list. A cause that is no longer stated can leave Alarms while the earlier record stays in Timeline and Activity.

Use Topology Tree and Knowledge Graph when dependency evidence exists. An unresolved or absent dependency is a limitation of the available evidence. Do not label the database as the cause merely because it is usually involved in the architecture.

05

5. Repair outside CTK and verify the result

Use your editor, terminal or deployment workflow to investigate further and make the change. CTK does not commit a patch or deploy a fix. Keep the observing watch running when appropriate, then compare a new successful reading with the earlier failure.

If you link a solution to a stated cause, Recommendations can show its relationship to subsequent readings. An empty Recommendations screen before a solution is linked is expected. A linked note is not proof that the repair worked; fresh evidence still matters.

06

What success looks like

You can state the observed failure, its source, its time and the later verification separately. If the record only supports “the health check failed,” preserve that uncertainty rather than writing “CTK proved the root cause.”