FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Establishing safe production operations and monitoring
Combining explicitly confirmed delivery and recovery, scheduled smoke checks, and local-service monitoring
Purpose
Post-release state checks, recovery after failure, monitoring of public and administrative boundaries, and local-service health were split across procedures, without enough mechanical protection against mistaken operations or missed verification.
Production operations needed to be limited to explicitly confirmed manual execution, avoid recording secrets, and verify the same conditions before and after release and after recovery.
Implementation
production delivery workflow added a manual workflow with deploy and rollback operations. It checks the target ref and confirmation text exactly and requires a UUID-form version for rollback. A new version is uploaded without traffic before the selected version receives 100% traffic.
deployment-metadata verification extracts only version IDs from structured output and requires one version at 100%. If post-release smoke fails, the previous version is rechecked and restored, followed by verification of both the restored active version and production smoke.
- Check the public page, public API, administrative redirect, rejection of the public administrative API, and the Access challenge on a schedule.
- Do not log redirect destinations or response bodies; evaluate only the expected Access host and path.
- Require the local Connector to be running and the scheduled Runner to be running or waiting with a successful last exit.
- Keep database migration separate from Worker delivery, with forward recovery, backup restore, and Access isolation in the runbook.
Because the current plan could not use environment approval features, the effective gate was fixed to manual invocation, a restricted ref, and exact confirmation. The operations document also records how to add environment protection and required checks after a plan upgrade.
The implementation separates deploy and rollback through exact confirmation and version inputs. Error text is omitted in this public account, while decision conditions are retained.
Rendering diagram…
What was confirmed
Verification results
Fifty-eight tests, linting, type checks, the Worker build, bundle secret scanning, and workflow syntax checks passed.
Five production-boundary smoke checks and local-service running, waiting, and last-exit decisions were verified.
The active version ID could be obtained from structured deployment data, while ambiguous gradual delivery and invalid IDs failed closed.
The operations workflow, monitoring scripts, and recovery runbook were applied to the target. Dedicated credential configuration and the first manual production run remained post-cutoff operational work.
Basis for completion
The work was complete when production approval conditions, version verification, failure recovery, public and administrative boundary smoke checks, local-service monitoring, and secret non-disclosure had been implemented and verified through static checks and tests.