Troubleshooting concepts

Establish the exact context

No Runtime troubleshooting commands are published yet. When a verified release exists, begin with its version, platform, configuration schema, and a minimal reproducible input. A symptom without that context is hard to compare with another result.

Follow the boundary

Symptom	First evidence to collect
Input rejected	Sanitized input shape and validation result
Downstream call fails	Destination class, response category, elapsed time
Timeout	Total budget, remote outcome if known, cancellation timing
Duplicate effect	Request identity and remote duplicate-handling contract
Rising latency	Queueing, resource limits, dependency response distribution

Keep raw credentials and personal payloads out of logs or reports. Use synthetic data when reducing a problem.

Build a timeline

Record when work was accepted, when each external boundary began, what completed, and when the caller stopped waiting. Distinguish missing evidence from evidence that nothing happened. The absence of a response is not proof that a remote write failed.

Reduce the scenario

Replace a remote dependency with a controlled test double where appropriate. Change one condition at a time. A useful report includes the smallest scenario, expected and observed results, safe diagnostic evidence, and the exact release context.

Know the publication limit

This guide does not name internal classes, settings, log formats, or recovery commands. Those details will be documented from verified Runtime tests rather than guessed. Read tests and observability for scenario design.