operate
Self-Healing Deploys
Checks Every 5 To 15 Minutes — Goes Dark, The Last Good Deploy Is Restored Automatically On A Managed Host.
What you get
Caught By A Monitor, Not A Customer
A synthetic check hits your live deployment every 5 to 15 minutes, depending on your plan — Studio, LoomWorks, Business, Agency and Agency Pro every 5; Free, Solo and Guild every 15. A failure is detected by ZipLoom before your users report it.
Rolled Back Automatically On A Managed Host
If a deploy goes dark, the previous good version is restored on its own and you get a notification after the fact — the app is already back up. On a self-managed VPS every deploy is a new server, so there is no earlier deploy to put back.
You Get The Timeline, Not A Surprise
When a rollback fires, ZipLoom records what the health check saw, which deploy it restored, and when — then notifies you. The app is back up by the time you read it, so the incident is documented rather than reconstructed from customer complaints.
How Self-Healing Works
- 1
ZipLoom runs a synthetic check against your live deployment every 5 to 15 minutes, at your plan’s cadence.
- 2
If the check fails, the deploy is judged unhealthy.
- 3
The previous good deploy is automatically restored.
- 4
You receive a notification that a rollback occurred.
What this check inspects
Whether the newly deployed release actually responds, from outside your network.
Error rates and health signals in the minutes after a release, when regressions surface.
Which previous release was known good, so a rollback has a target.
What the health check saw at the moment it decided to roll back, recorded for afterwards.
What it means when this fails
Without this, a bad deploy stays live until a human notices — often a customer, often hours later, often overnight. With it, the app is already back on the last good release by the time you read the notification, and the incident is documented rather than reconstructed.
Questions
- What if the rollback is wrong?
- You see what triggered it and which release was restored, and you can redeploy deliberately. A false rollback costs you a redeploy; a missed one costs you an outage.
- Does this work on any platform?
- It needs a previous release it can put back, so it covers the managed hosts — Cloudflare, Vercel, Netlify, Render, Railway, Cloud Run and AWS. It does not cover a self-managed VPS (Vultr, Contabo, DigitalOcean, Amazon Lightsail): ZipLoom cannot yet restore an earlier version there. ZipLoom says that on the deploy’s own timeline rather than leaving you to discover it, and when a deploy replaces a server it shuts the old one down so it stops billing.
- Is this the same as uptime monitoring?
- No. Monitoring tells you it broke. This puts the last working version back.
What it replaces
Better Stack Uptime
Uptime monitoring, on-call and status pages. Tells you it broke; doesn't roll the release back.
Checkly Starter
Synthetic API and Playwright browser checks. Team plan $64/mo for all regions.
ZipLoom Solo — every deploy check included
Deploy, security scan, and monitoring in one flat price. Guild $40/mo · Studio $70/mo · LoomWorks $149/mo · Business $299/mo.
Related features