CapordiaDescribe the impact before proposing a cause
Give an observable sentence: some jobs no longer produce output, an authorized access is denied or an export can no longer be read back. Specify the scope affected and what continues to work. "The server is down" quickly becomes an overly broad conclusion when only one output path is failing. Count accepted, incomplete and unstarted results using mutually exclusive categories.
Name a coordination lead and a person authorized to intervene. Google SRE's incident management guide distinguishes coordination from operations and communication. In a small team, one person may hold several roles, but everyone must know who decides. Set the next internal status update; this organization creates no guaranteed response time from the provider.
Keep a timeline that distinguishes the facts
Note the last known good state, the first symptom and the changes that occurred in between. Give the time zone and the source of each time: log, direct observation or recollection to be confirmed. A date copied from a screenshot does not necessarily share the same reference as the application log. If a boundary is missing, keep the uncertainty interval rather than inventing a precise minute.
For each action, note the author, the scope, the objective and the result. "Restart performed" is incomplete without knowing which process was involved and whether the symptom changed. Keep observation, hypothesis and decision separate. This separation will make it possible to reconstruct what actually helped and to prevent several people from simultaneously trying incompatible remedies.
Fictional example: a partial export, not a demonstrated GPU failure
In the fictional cell "Shore Maps," twenty documents are to be delivered. Fourteen outputs have been opened and accepted, four jobs report a write refusal, and two have yet to be launched. Six results are therefore not yet deliverable, but it would be wrong to announce twenty lost results. No real incident or Capordia server is described by this example.
The timeline below leads to requesting a targeted review of the output path. It does not yet prove the cause: the change that occurred close in time may be related to the symptom without explaining it. The team keeps the fourteen accepted outputs and suspends only the affected new submissions. The times are fictional and belong to the same time zone, chosen to avoid any ambiguity in reading.
| Time | Logged event | Permissible interpretation |
|---|---|---|
| 9:40 a.m. | Last output opened successfully | Known operating boundary |
| 9:42 a.m. | Output destination changed | Change to examine |
| 9:43 a.m. | First logged write refusal | Observed onset of the symptom |
| 9:48 a.m. | Affected new submissions suspended | Impact limitation measure |
| 10:05 a.m. | Same refusal with a small fictional file | Smaller reproduction, cause to be confirmed |
Reduce the reproduction without erasing the defect
Look for the smallest input that preserves the symptom and the same relevant path: file type, destination, technical identity or setting. Replace the business content with synthetic data when possible. If the substitution makes the error disappear, document that limitation. Do not present a simplified command that no longer traverses the suspected part as a faithful reproduction.
Proceed by verifiable hypotheses. The Google SRE troubleshooting chapter recommends tests that can distinguish between causes and notes that instrumentation or tests can influence the system. So record a negative result as carefully as a success. Avoid repeatedly re-running a job that publishes outputs or worsens storage; the person in charge first sets the scope of the authorized test.
Prepare readable, redacted evidence
The handover package contains the relevant versions, the minimal procedure, the times, the exact error message and a log excerpt around the symptom. Add the job identifier and the reference of the affected folder when this makes matching easier. Set aside the rest of the logs if no one needs them to understand the situation. Keep the originals within the team's authorized scope.
OWASP notes that logs must not expose, in particular, passwords, access tokens or keys. Also review paths, file names and arguments that may reveal the project. Use consistent placeholders, such as PROJECT_A, while keeping the structure needed for diagnosis. Redacted evidence must state what has been removed; it must neither alter the decisive error message nor make an important condition disappear.
Write an escalation request that enables action
Open the request with the impact and the precise question: review an access refusal, confirm an allocation property or help locate a reproducible discrepancy. Attach the timeline and the redacted reproduction. State the actions already attempted, those that changed nothing and the operations to avoid. The recipient must be able to know what is expected without digging through an uncommented folder of screenshots.
In the example, the request may be: "The newly used output path refuses writing under the job identity; please review the permissions applicable to this path. Fourteen outputs remain validated; four jobs reported a write refusal, and this refusal was reproduced with a fictional input." This text does not blame the GPU or an operator. It sets out what is known and leaves the cause open until it is reviewed.
Verify the return before closing
An error that no longer reproduces is not always enough. Verify a complete result with the same identity, the same decisive conditions and a destination that has been reviewed. Then check the affected items: are already accepted outputs preserved, are partial outputs isolated and are the remaining tasks correctly identified? The person responsible for the results must confirm the useful recovery, distinctly from the success of a technical command.
A migration is an organized change made before moving the work; an incident begins with an unexpected deviation. If resolving it requires moving data or resuming an interrupted process, then use the existing migration file for that operation. The incident timeline preserves the reason for that decision; it does not rewrite the cutover method or the batch log.
Keep a usable conclusion, even if the cause remains open
Close with the final impact, the verification result, the cause demonstrated or still unknown, and the actions decided. A workaround can restore a result without resolving the underlying problem: state this clearly and name the person responsible for following up. An absence of evidence must not become "no incident"; a resemblance to an old case must not become a certain cause.
The final review must allow another person to distinguish what was observed, what was attempted and what remains to be verified. It serves to improve a procedure, a control or an error message, not to fabricate a narrative without uncertainty. No number of screenshots, log volume or urgency level replaces this quality of handover.
Questions to decide
Should you wait to know the cause before reporting an incident?
No. Report a verifiable impact and the known scope, then clearly separate the hypotheses. A timeline and a targeted reproduction often help before the cause is demonstrated. Also state the measures already taken to limit the impact.
Can I send all my logs to save time?
First prepare the useful excerpts and review them. Complete logs may contain secrets and project data without helping the diagnosis. Keep the originals in an authorized space and explain the redactions made in the version transmitted.
When should the case be considered closed?
After a check of the expected result and an explicit decision by the responsible person. Distinguish confirmed repair from temporary workaround. Closure may keep a cause unknown, provided the limits, the check performed and the actions still open are named.