Deploy Watch: automatic recovery after failed post-deploy checks
A release can pass its startup check and fail a minute later. The process is still running, but its readiness endpoint now returns an error.
Deploy Watch adds a short automatic watch window after an eligible deployment. When checks repeatedly fail, Upferry attempts to start and verify the previous image before returning traffic to it.
v1: 200✓ Check before switchingv2: 500× Three failuresWhat happens after a release
Upferry checks the configured healthcheck roughly every 15 seconds for 10 minutes. A successful check clears the consecutive failure count. Three consecutive failures begin one recovery attempt.
The previous image is pinned against normal image cleanup. Its process is stopped after the normal deployment handover. During recovery, Upferry starts that exact image without rebuilding, checks it, transfers traffic and confirms the selected route.
Starting the previous image takes time. Detection and startup can both contribute to downtime. If the image is missing, resources are unavailable or readiness fails, the panel reports an unconfirmed recovery rather than claiming success.
Enable it for a compatible service
Open a service, go to Settings and expand Deploy Watch. The setting is shared by its environments, while each watch belongs to a particular deployment and environment.
- Configure a healthcheck that represents the readiness you want to watch.
- Confirm the application requirements and enable Deploy Watch.
- Deploy a healthy baseline, then a code-only change with the same runtime configuration.
The first version covers one HTTP instance without a volume, cron schedule or pre-deploy command. A matching healthy previous release is required. Switching the setting on does not retroactively protect a running release.
Application compatibility matters
The owner must confirm that startup does not run database migrations or background consumers, timers or other side effects. Briefly running two versions must be safe. The current database, accepted writes and peer services must remain compatible with the previous code.
These are application requirements confirmed by the owner. Upferry cannot prove them by inspecting an arbitrary Docker image. Returning an image does not undo schema changes, customer actions, payments or external requests.
Deploy Watch recovers one service. It does not coordinate a rollback of an entire stack.
Current settings stay current
Deploy Watch does not restore historical secrets or loosen the network policy. An eligible release has the same effective runtime configuration and variables as its healthy baseline.
A newer deployment, manual lifecycle action or relevant configuration change cancels the old watch. Its recorded state survives a worker restart. Before recovery is confirmed, Upferry checks that the attempt still belongs to the current deployment.
Know what the check covers
The check targets the selected version directly, using its existing allowed ingress when network permissions are restricted. A generic endpoint that always returns 200 cannot detect a broken checkout, image processor or login flow.
Public DNS, TLS, proxy faults and functions outside that endpoint are not checked. Deploy Watch ends after its watch window and does not replace continuous monitoring. The service history shows failed checks, recovery states and the reason for a cancelled or unsuccessful attempt. Configured notification channels can report the outcome.
How this compares with Railway
Railway documents healthchecks before a deployment goes live, and explicitly says those checks do not continue afterwards. Its deployment actions include a manual rollback.
We did not find this integrated post-deploy watch and automatic recovery flow in the public documentation we reviewed on October 27, 2026. Similar automation can be assembled using monitoring, scripts and the Railway API.