Redash dashboard query failed: data source connection timeout error fix

TL;DR

Check the path from the Redash worker to the data source first. Confirm the source host and port are reachable from the Redash deployment, confirm the source is not paused or out of workers, and test the connection from the data source page before editing any query. A connection timeout means the query never reached the database, so SQL tuning comes after connectivity.

Redash dashboard query failed: data source connection timeout error fix

Use this when

• Redash queries fail with a connection timeout while the same database answers other tools.
• The failure started after a network, VPN, or database host change.
• The data source test connection also times out or takes unusually long.

Not for this skill when

• Queries connect and then fail with a database error message. Debug the returned error instead.
• One query is slow but completes. That is a query performance issue, not a connection timeout.

Steps

1. Open the data source page in Redash and run the test connection, timing how long it takes. Verify: the test either fails with the same timeout or completes far slower than normal
2. From the Redash worker host or container, check reachability to the database host and port with a basic network test. Verify: the port accepts a connection from the worker network location
3. Review recent network changes, security groups, allowlists and VPN state that cover the worker address range. Verify: the worker addresses are allowed to reach the database port
4. Check the database for connection limits, a paused state, or heavy load that delays connection setup. Verify: a direct client connection from a similar network completes quickly
5. Run a trivial query such as a select of the current time through Redash once connectivity is restored. Verify: the query returns in seconds through the same data source
6. Re-run the originally failing query and the scheduled refreshes that depend on the source. Verify: scheduled executions complete and dashboards show current data

Why it happens

Connection setup is a separate stage from query execution, and Redash reports it separately. Timeouts at this stage are infrastructure shaped, so they tend to affect every query on the source at once and to start at a change boundary such as a network edit or a database failover. Confirming the worker to database path first avoids wasted effort rewriting healthy queries.

Redash runs queries through its worker processes against the configured data source. A timeout at connection time points at network rules, a changed host or port, a VPN or allowlist change, or a source that accepts connections too slowly under load. Because the Redash test connection and the scheduled workers can run in different places in some deployments, a passing ad hoc run does not always prove the worker path is healthy.

Field notes for Redash specifically. The job and worker state, the data source page test, and the query execution history show where a failure sits, and self hosted Redash splits web and worker processes, so evidence from only one side misleads. Because Redash is often self hosted on modest infrastructure, worker saturation is a recurring hidden cause, a few heavy scheduled queries can delay everything else on the instance. Checking the queue depth during an incident is a thirty second step that separates an overloaded instance from a broken source.

For Redash teams, scheduled query hygiene is the reliability lever. Stagger heavy refreshes away from the top of the hour, retire queries nobody has opened in months, and give the busiest data sources their own review for connection limits. Redash instances tend to accumulate years of scheduled queries whose owners have moved on, and the estate slows and fails in ways that look like platform problems. A quarterly prune of orphaned schedules usually restores more performance than any infrastructure change the team was considering.

Variants and edge cases

Redash data source connection timeout all queries fail

The all-queries variant that signals an infrastructure cause.

Redash query runner timeout network allowlist fix

The allowlist-focused phrasing for cloud databases.

Redash scheduled query failed connection timeout worker

The scheduled-run variant where workers differ from the web app.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yigWQvVNH3Sq4PSOn3cwqw