Greenhouse 404 "job not found" when the agent reads a req that was deleted overnight

Greenhouse 404 "job not found" when the agent reads a req that was deleted overnight

TL;DR

The req was deleted overnight and the agent's sync still references it. Treat 404 on a job as a signal, not an error: mark the local copy deleted, stop syncing it, and alert if the deletion was unexpected. Jobs vanish; syncs must handle it.

404 Not Found: "job not found" (Greenhouse Harvest API, job deleted overnight)

Steps

1. Confirm the deletion: check the Greenhouse UI or audit log for the job ID. Expected: The job is gone, deleted at a known time.

2. Mark your local copy deleted instead of retrying: a 404 on a job is a fact, not a transient. Expected: The sync stops hammering a dead ID.

3. Check whether the deletion was expected (req filled or cancelled) or a surprise. Expected: You know whether to alert.

4. If unexpected, find who deleted it and whether candidates need rerouting to a replacement req. Expected: The fallout is handled.

5. Add 404 handling to the sync: on job 404, tombstone locally and notify, never retry. Expected: Future deletions are handled gracefully.

When to use

• Greenhouse returns 404 "job not found"
• the job existed recently
• the agent syncs job data

When not to use

• the job ID was always wrong (a typo, not a deletion)
• the 404 is on a candidate, not a job (different endpoint, different meaning)
• the job is archived, not deleted (archived jobs have their own status)

Tool compatibility

• Greenhouse Harvest API
• job sync workflows

Variant phrasings

• "greenhouse 404 job not found"
• "job deleted overnight greenhouse"
• "greenhouse job not found sync"

Why it happens

Reqs get deleted when roles are cancelled or merged, often overnight by an admin cleaning up. The agent's sync list goes stale, and the first sign is a 404. Retrying a deleted job is pointless; the correct response is to accept the deletion and update local state.

Edge cases

• distinguish deleted from archived; they need different local handling
• the audit log shows who deleted it; that context decides whether to alert
• tombstones need their own retention policy

Provenance

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