## TL;DR
The connection dropped mid-check: Redshift closed an idle connection, the network path broke, or the cluster restarted. The agent should reconnect with backoff, keep the check query trivial, and treat a dropped check as unknown, not as stale. Freshness unknown is honest; freshness stale is a claim the agent cannot support.

```text
redshift connection dropped when agent tried checking table freshness, check failed
```

## Use this when
- Agent Redshift freshness checks fail on dropped connections.
- The check query is simple but the connection dies.
- It happens intermittently.

## Not for this skill when
- The check runs but reports old data. That is a freshness problem.
- Connections fail immediately. That is auth or networking.

## Steps
1. Retry the check with a fresh connection and short backoff. Note the retry. Verify: transient drops are absorbed
2. Keep the check query minimal: one timestamp lookup, no joins. Note the lean query. Verify: the check holds the connection briefly
3. On repeated drops, check cluster health: restarts, maintenance, load. Note the cluster state. Verify: cluster problems are found
4. Report unknown rather than stale when the check cannot complete. Note the honest verdict. Verify: the agent does not invent data
5. If drops are chronic, move the check to a more reliable path or schedule. Note the change. Verify: the check is sustainable

## Variant phrasings
### redshift connection drop intermittent
The symptom phrasing.
### redshift freshness check query
The check-shaped search.

Compatibility: Amazon Redshift. Connection behavior is the same for provisioned and serverless.

## Why it happens
Freshness checks hold a connection open just long enough to ask one question, which makes them sensitive to exactly the failures that long-lived connections ride out: idle timeouts, brief network blips, cluster maintenance. A dropped check is not evidence about the data; it is evidence about the connection. Agents that report stale on a dropped check manufacture a data incident out of a network hiccup. Unknown is the only honest verdict, and it is actionable: it says check the connection, not the data.

## Edge cases / pitfalls
- A check that always reports unknown is a broken monitor wearing honesty as an excuse. Fix chronic drops; do not normalize them.
- Connection pools with aggressive idle timeouts drop the check's connection between runs. Tune the pool or connect fresh each time.
- Cluster maintenance windows drop all connections on schedule. Coordinate check schedules with maintenance.
- The freshness timestamp column itself can be the problem if it stops updating. Distinguish check failure from data staleness explicitly.

## Provenance

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