# Troubleshooting overview

Begin with the failing action and its exact result. A connection refusal, authentication error, invalid statement and failed value conversion need different evidence. Changing several settings at once makes the cause harder to identify.

## Choose a starting point

For connection failures, confirm the hostname, port, listener and route from the affected client. Use HTTP `/ping` when available, then a small authenticated SELECT. For SQL failures, keep the exception code, query identifier, selected database and a reduced statement. For ingestion failures, add the destination schema, selected format and a small redacted input sample.

Completed request events in `system.query_log` can show duration, resource counters and an error. `system.processes` describes work still active. Metadata queries need the documented columns; copied diagnostic SQL for another product can introduce a second unrelated error.

## Preserve the outcome of writes

A lost connection does not prove that a write failed. Check the destination with stable application identifiers before retrying. For a data repair, preserve a verified copy and test the procedure on independent data first.

Share only the minimum reproduction needed to demonstrate the problem. Remove passwords, API keys, private hostnames and business records without removing the condition that triggers the failure.

See [diagnostic workflow](https://coordinatordb.com/docs/resources/support-center/troubleshooting/troubleshooting), [HTTP status codes](https://coordinatordb.com/docs/concepts/features/interfaces/http) and [query history](https://coordinatordb.com/docs/reference/system-tables/query-log).