## TL;DR

The monitor gave up, not the job: bulk jobs queue behind other work and can take far longer than a naive timeout allows. Poll the job state with exponential backoff up to a generous cap, and treat Queued and InProgress as healthy. Monitor the job, do not race it.

## Error

```text
Agent timeout: bulk job 750... still InProgress after 30 minutes; monitor gave up.
```

## Steps

1. Check the job state directly: it is probably still InProgress or Queued, not failed. Expected: you confirm the job is alive.
2. Replace the fixed timeout with polling: check every 30 seconds, backing off to a few minutes, with a cap in hours. Expected: the monitor outlasts the queue.
3. Log each state transition with timestamps. Expected: visibility into queue vs processing time.
4. If the job sits in Queued for very long, check org concurrency and other running jobs. Expected: you find the contention.
5. Only alert on Failed or Aborted states, not on slowness. Expected: alerts mean action is needed.

## When to use

- Monitors time out while the job is still running.
- An agent kills and restarts jobs that were actually fine.
- After enabling many parallel bulk jobs.

## When not to use

- Jobs that actually fail (check the job results).
- API timeouts on single calls (different problem).

## Tool compatibility

- Salesforce Bulk API job status polling.
- Agent monitor loops.

## Variant phrasings

### monitor timed out on InProgress job

Poll longer; the job is fine.

### bulk job taking too long

Check queue depth before assuming failure.

## Why it happens

Bulk jobs share org concurrency. A job submitted behind others waits, and monitors written against empty-org timings declare it dead.

## Edge cases

- Aborted jobs stay visible; distinguish Aborted from slow.
- Very large jobs legitimately take hours; size the cap accordingly.
- Do not submit a duplicate job when the monitor times out; check state first.

## Provenance

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