## TL;DR
An Athena query stuck in QUEUED or RUNNING past the agent's timeout is either waiting for resources or scanning far more data than expected. Check the query execution state and data scanned, cancel the stuck query to stop the meter, and rewrite it to scan less. Athena bills by data scanned, so a stuck query is also an expensive query.

```text
agent timed out waiting for athena query results, query stuck
```

## Use this when
- An agent waits on an Athena query that never returns.
- The query sits in QUEUED or RUNNING.
- The agent's timeout fires first.

## Not for this skill when
- The query fails fast with a syntax error. Fix the SQL.
- Results return slowly but do return. That is performance tuning.

## Steps
1. Check the query execution state and how long it has been there. Note the state and age. Verify: the stall is characterized
2. Look at data scanned so far versus the table size. Note whether it is scanning the whole table. Verify: the scan scope is known
3. Cancel the stuck query to stop billing. Note the cancellation. Verify: the meter stops
4. Rewrite to scan less: partition filters, column pruning, limit the time range. Note the rewritten query. Verify: the query is cheaper
5. Re-run with a bounded wait and confirm results return. Note the success. Verify: the fix is verified

## Variant phrasings
### athena query stuck running
The symptom phrasing.
### athena cancel stuck query
The fix-shaped search.

Compatibility: Amazon Athena. Query execution states and cancellation are console and API operations.

## Why it happens
Athena is serverless, which means queries queue for shared resources and scan-based billing punishes unfiltered queries. A query stuck in QUEUED is waiting its turn; a query stuck in RUNNING is usually scanning vastly more data than the author intended, often a missing partition filter on a huge table. Agents that fire SQL without checking the scan estimate discover this via timeout. Cancelling is both the diagnostic and the cost control: it stops the bleeding while you rewrite.

## Edge cases / pitfalls
- QUEUED during regional capacity crunches can last a long time and is not the query's fault. Check Athena service health.
- A LIMIT does not reduce data scanned; it only reduces returned rows. Partition filters reduce scanned data.
- Workgroup settings can kill queries past a data-scanned threshold. A killed query looks stuck-then-failed; check the workgroup.
- Concurrent query limits per workgroup queue the excess. One agent's many parallel queries can self-throttle.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gcPkaZ-BljruR4bgL9Vs_g