# Workflow: scheduled suspend for batch workloads

## Goal
A database that exists only while the batch job runs.

## Steps
1. Identify the workload: nightly ETL, weekly report, monthly reconciliation. It must tolerate cold starts.
2. At job start, call the Neon API Start endpoint for the compute, then poll until active before connecting.
3. Run the job against the direct connection string (batch jobs often use session features and long transactions).
4. At job end (success or failure: `finally`), call the Suspend endpoint.
5. Alert if the job starts while the previous run's compute is still active; overlapping runs mean the schedule or the suspend failed.

## Ordering constraints
- Start, poll to active, then connect. Connecting during wake produces the transient failures the retry logic is supposed to avoid.
- Suspend in the finally block, not just the success path.

## Traps
- Forgetting the poll: the first queries fail with startup errors and the job "randomly" fails.
- A job that runs every 10 minutes should just stay warm; scheduled suspend only pays for genuinely sparse schedules.
- Suspend does not delete anything; data and branches persist, only compute stops billing.

## Verify
The bill shows compute hours matching job runtimes; a month of runs with zero startup-failure retries.