Query Timeout
A long-running query can hold cluster resources indefinitely. We bound that with a per-job timeout: once a run exceeds its limit, we terminate it automatically, which stops one pathological query from occupying an autoscaled cluster's capacity for hours while everything queued behind it waits.
The default is no timeout at all, so this is something you opt into.
Where the setting lives
The timeout is a job setting, not a cluster setting. It's in Advanced Options on the Create Job form:
| Section | Field | Default | Help text |
|---|---|---|---|
| Timeout | Job Timeout (minutes) | 0 | "Maximum allowable time that a job is permitted to run before it's automatically terminated." |
0 means no timeout. The run continues until it finishes, errors, or is stopped.
A terminated run ends in the TERMINATED status, which we keep distinct from STOPPED (stopped deliberately by a user) and ERROR (the job itself failed). That distinction is worth knowing when you're reading run history, because a wave of terminated runs points at a timeout configured too tightly rather than at anything wrong with the code.
Functions jobs have their own timeouts
A job of type Functions is long-lived and serves requests, so it uses two different timers instead:
| Field | Meaning |
|---|---|
Job Timeout(seconds) | How long a job instance may sit with no incoming requests before it is shut down. The timer counts idle time only — it resets on each new request and does not limit how long an active request may take. |
HTTP Request Timeout | How long the proxy waits for a job instance to respond to a request. If no response arrives in time, the request fails with a timeout error even though the instance may still be running. |
Related: idle clusters
A timeout stops a run. To stop an idle cluster, use Auto Shutdown
(Stop Each Instance After [N] Minutes Of Idle Time), described in
Auto Suspension.
Related pages
- Create Job, the Advanced Options section
- Auto Suspension
- Warm Start/Stop Mechanism