Skip to main content

watch-deploy

After a PR merges, watch the deployment land and stay healthy before the task is allowed to close. This is the deploy-bridge half of /continue step 13 and feeds the last item of the Definition of Done — a clean post-deploy window.

Vendor-neutral by design: the org runs Grafana Loki / CloudWatch (moving off Datadog). Query whatever the target service emits; never hardcode a single vendor.

Steps​

1. Identify the deployment​

From the merged PR, determine the target environment from the deploy tag/branch (us-prod, fr-prod, staging). Find the deployment via gh api repos/bewith-dev/<repo>/deployments (and .../deployments/<id>/statuses) or the repo's deploy workflow run (gh run list --workflow deploy.yml).

2. Wait for the deploy to succeed​

Poll the deployment status / workflow run until it reaches success (or failure). On failure: stop, surface the failing step, and do not close the task — hand to devops-infra.

2b. Verify the live runtime is the deployed commit (when the service exposes it)​

A green deploy workflow says "the pipeline finished" — not "the new code is actually serving." The reliable confirmation is to ask the running service what it is:

  • Hit the target environment's GET /version (per the versioning & release-notes standard, Layer 3) and read {version, commit, builtAt}.
  • Assert commit equals the commit this deploy shipped — cross-checked against the Layer-4 deployment record (the deploy-intent). The record is intent; the endpoint is live runtime.
  • Match → the rollout completed; proceed to the observability window. Mismatch, or a stale builtAt → the old task is still serving / the rollout didn't complete → treat as a bad/partial deploy, do not close, raise an incident (step 4).

Gated on the exposure contract existing. As of the 2026-06-04 audit (workflow wqnvpdccm), no bewith-dev service exposes commit/builtAt yet, and /version is inconsistent (backend-services /service_info returns a hardcoded 0.0.1; most services expose nothing). Until the standard's Layers 2–3 land, skip this step and say so — fall back to the deploy-workflow status (step 2) + the observability window (step 3). Never assert a commit match against an endpoint that doesn't return the commit.

3. Watch the observability window​

For the defined window (default 30 minutes post-deploy), check the service's telemetry for regressions attributable to this deploy:

  • Errors / logs — error-rate spike vs. the pre-deploy baseline (Loki / CloudWatch Logs). Reuse the obs-logs skill for the query.
  • Metrics / alerts — latency, 5xx, saturation; any monitor that fired during the window matching the deployment.

Defer the what to emit / which monitors matter judgment to observability.

4. Verdict​

  • Clean → report success; /continue step 13 / /done may move the ClickUp status to Done.
  • Regression → do not close. Flag an incident, summarize the signal (error/metric + timestamps + deployment id), and route to devops-infra / observability. Record the watch outcome in the task's AI Context via state-sync.
  • Window not yet elapsed (long bake) → report the partial result and mark a delayed-close on the ClickUp task (the DoD process-guardian allows this as a WAIVABLE-with-attestation item); do not fabricate a clean window.

Boundaries​

  • Vendor-neutral. Query whatever the service emits; do not assume Datadog.
  • Does not deploy or roll back. It watches and reports; deploy/rollback actions are devops-infra.
  • Never fakes a clean window. No telemetry access → say so and mark a manual delayed-close, never a green checkmark.

Cross-references​