# Useful diagnostic SQL queries

Start with read-only observations that identify which database and requests are involved. Through the server, use the `system` qualifier for diagnostic tables; an unqualified application table with the same name is a different object.

```sql
SELECT query_id, user, elapsed, query_kind
FROM system.processes
ORDER BY elapsed DESC
LIMIT 10;
```

This snapshot shows requests still active, including response delivery. A request can finish between observations. Query history answers the separate question of what completed or failed:

```sql
SELECT event_time_text, query_id, exception_code, exception
FROM system.query_log
WHERE type IN ('ExceptionBeforeStart', 'ExceptionWhileProcessing')
ORDER BY event_time DESC
LIMIT 10;
```

Check effective database limits before assuming a request used built-in defaults:

```sql
SELECT name, value, changed
FROM system.settings
WHERE changed
ORDER BY name;
```

Save the query ID, exact error and relevant setting values with the report. Redact credentials and private SQL values before sharing output. Query logging may omit short requests when a duration threshold is configured, so absence from history alone does not prove that a request never arrived.

See [system tables](https://coordinatordb.com/docs/reference/system-tables/overview) and [query logging](https://coordinatordb.com/docs/reference/settings/session-settings/log-queries).