Fix readiness and daemon problems

Resolve required readiness failures

Open the database readiness panel. A required failure blocks query analysis; recommended and optional issues may reduce coverage without blocking the run.
Expand the failed check. Use the provided SQL or configuration instruction. Run administrative statements with an appropriately privileged account, not the least-privilege collector account.
Run checks again. The panel replaces the previous result set only after the new probe completes.

Fix a failed database connection

Connection refused

Confirm that the database is running and accepting connections on the saved host and port.

Timed out

Check routing, firewall rules, network allowlists, and whether the database endpoint is reachable from the selected direct, SSH, or CLI transport.

Host not found

Correct the hostname and verify that DNS resolves it.

Sign-in rejected

Update the saved username or password and confirm that the account may connect from the transport host.

Secure connection failed

Review the SSL mode, certificate chain, server name, and certificate validity.

Database not found

Correct the database name. For PostgreSQL, keep the database name separate from the schema selection.

Save the corrected connection, then run readiness again. Do not paste credentials, connection strings, private keys, or certificate contents into a thread or support request.

Recover an offline CLI daemon

An offline daemon makes prior readiness results stale. On the host where dbtempo is installed, run dbtempo status, inspectdbtempo logs, and restart the configured service when needed. Then return to the readiness panel and run checks again.

Use dbtempo doctor

dbtempo doctor

Fix the first failing prerequisite, then rerun the command; later checks may be skipped or depend on it.

Config file

Run dbtempo login and dbtempo init to create or repair configuration through the CLI.

API key

Create or rotate a key in Settings → API Keys, then run dbtempo login with the new key.

DB connection

Resolve the reported endpoint, network, credential, TLS, or database-name failure.

Performance Schema

For MySQL or MariaDB, enable it and grant the collector read access, or use the slow-query log as the query source.

Slow query log

For MySQL or MariaDB, enable it and make its configured file readable, or use Performance Schema.

Credits

Open Settings → Billing to top up or review the current plan before retrying the analysis.

No query source or slow queries are available

MySQL and MariaDB collection need Performance Schema or the slow-query log. PostgreSQL live collection needs pg_stat_statements. Use the readiness panel's engine-specific remediation, verify that the collector user can read the enabled source, and rerun readiness before starting another analysis.

A source can be ready but return no relevant queries. Confirm that the project points to the intended database or schema, that representative application traffic occurred, and that the project's slow-query threshold matches the workload you expect to inspect. Wait for new observations, then run the project again.

Recover from exhausted credits or rate limits

When credits are exhausted, an active run stops and may report that later queries were skipped. Open Settings → Billing to top up or review usage, then start a new run. A stopped run does not automatically resume.

A rate-limit message is temporary and does not mean credits were spent. Wait for the indicated retry period, avoid repeated submissions, and send the request once more. If the message persists after the window, check the service status or contact support without including SQL, credentials, or other customer data.