Deploy Watchdog
helio / deploy-watchdogA 'deploy succeeded' notification isn't the same as a working site. Your AI teammate checks the real thing after every release, then patrols uptime and certs every day after that.
After every deploy to Vercel, fetch our homepage, pricing page, and /api/health, and confirm the new version is actually live and not a stale cache. Then run a daily patrol on uptime, error rate, and certificate expiry. Ask me what you need before you start.
Swap in your own key pages, endpoints, and deploy platform.
What is Deploy Watchdog?
A teammate that fetches your key pages and endpoints after every Vercel deploy and checks them against what was supposed to ship, calling out a stale edge cache by name instead of trusting the 'deploy succeeded' notice. It patrols uptime, error rate, and certificate expiry once a day, stays silent when healthy, and prepares a rollback but executes only one you approve in advance.
What it does
Any chatbot checks a URL once. Helio runs it as a standing job — from your context, kept current, delivered to you.
| Owns the job, not just the check | It confirms the new version is visible on the page and rolls back only with your prior approval. |
| Runs again without starting over | Saved once it works, it re-fires on every Vercel deploy and again on a daily patrol, with no manual re-check. |
| Works from your context | It reads your GitHub build events and the exact pages that reflect whether the release landed. |
| Keeps itself current | Add a page or endpoint to watch and it updates the check set. You don't rewire the monitor. |
| Lands where you work | One DM to Slack, Lark, or email when something breaks, silence when it's fine. |
Three things it gets right
Verifies the shipped change
It checks that the specific thing you shipped is visible on the page, catching a stale cache still serving the old build.
Cert expiry with lead time
Certificate expiry is flagged early enough to renew calmly, before a customer hits the warning.
Error rate against a baseline
It compares error rate against your normal baseline, so a real spike stands out from routine noise.
What Deploy Watchdog connects to.
Questions
- How is this different from my host's own uptime monitor?
- Most uptime monitors only check that a server responds. This checks that the specific thing you just shipped is actually visible on the page — a subtler and more common failure mode.
- What happens when it finds a problem?
- It reports what it found and, where the fix is well-understood (like a cache purge), can propose or take the fix — always with what changed logged.
- Does it need access to my production environment?
- It only needs the URLs to check and, optionally, GitHub access to correlate failures with specific commits — no production database access required.
- Can it handle a rollback?
- It can prepare a rollback plan and execute one you've approved in advance, but it doesn't decide to roll back unilaterally.
Know your deploy actually worked.
Point Helio at your key pages and endpoints — it verifies every release and patrols uptime every day after.
Ask about this automation