What can go wrong with this loop?

Polls too fast and burns tokens — prefer self-pacing or event push Reports 'done' on a transient state if it doesn't check for terminal status

Deploy Poller

Watches a deploy you just kicked off and tells you the moment it finishes — or breaks

L1 · Poller Poller Low risk Supervised Dynamic / self-paced production

What it does

Free you from refreshing a deploy dashboard by having the agent watch it and report state changes.

Stops when

Deploy reaches a terminal state (succeeded or failed) and has been reported once.

Runs

short waits while deploying, stop once terminal · Supervised

How one iteration works

discover → plan → execute → verify → escalate

1
Discover
Query the deploy/CI status for the current release.
2
Plan
Decide whether anything changed since last check.
3
Execute
If still running, wait. If it just reached a terminal state, summarize what happened.
4
Verify
Confirm the status is actually terminal (not a transient in-progress blip) before declaring done.
5
Escalate
On failure, pull the failing step's log and surface the error to the human.

The prompt

The tool-agnostic spec the loop runs each pass — copy it, then wire it to your tool below.

Check whether the current deployment has finished. If it is still running, wait and check again later, spacing checks out as it drags on. The moment it reaches a terminal state, tell me succeeded or failed in one line. If it failed, fetch the failing step's log and show me the error. Then stop.

Claude Code

/loop check if the deployment finished and tell me what happened

Generic

while ! deploy_terminal; do agent -p 'check deploy status, summarize if changed'; sleep 60; done

Memory contract

Stateless — each check reads live status; the conversation itself holds 'last reported state'.

Verification & guardrails

How it checks itself. Treats a status as final only when the provider reports a terminal state; ignores in-progress flapping.

Read-only: never re-triggers or rolls back a deploy on its own
Stops itself once a terminal state is reported

Failure modes

Polls too fast and burns tokens — prefer self-pacing or event push
Reports 'done' on a transient state if it doesn't check for terminal status

Variations

Fixed cadence. Pin it with a 2-minute interval instead of self-pacing if your provider rate-limits status calls.
Event-driven. If your CI can push a webhook, react to the completion event instead of polling at all.

Example run

Still building (3m elapsed)... still building (6m)... Deploy FAILED at step 'migrate'. Error: relation "users" already exists. Here's the last 20 log lines.