- Headline result
- Deploys fix themselves
- Client
- My own deployed apps and databases
- My role
- Designed and built it
- Scope
- Vercel + Supabase APIs every 15 minutes, provider emails via n8n
- When
- September 2026
The problem
I run a handful of deployed apps and databases. Providers email me when something breaks: a failed build, a paused project, a stale deploy. Those emails landed in an inbox I read once a day, so a broken deploy could sit for hours. A build that failed at 3am meant a page stayed broken until I woke up and read about it.
Most of the fixes were the same three moves every time. Re-run the build with the error fixed. Restore the paused project. Redeploy the stale one. Repetitive, rule-based and boring, which is the definition of work a system should do.
The part that is not boring is deciding when a fix is safe. That decision should stay with a human, but it should take one tap, not a login and a dashboard.
What I did
An agent that polls the Vercel and Supabase APIs every 15 minutes, reads forwarded provider emails through an n8n intake and sorts every event into one of three buckets: fix it, ask me or just tell me.
Vercel + Supabase APIs every 15 min, plus provider emails via n8n → classify → auto-fix (safe) / Telegram approval (judgment) / Telegram notice (info) → verify → log.
The safe bucket covers a failed build on a mapped repo (clone, let the model fix the error, push, verify the redeploy went green), a paused database project (restore and confirm) and a stale deploy (redeploy and check). Everything else is either a one-tap approval or a notice.
Every action is logged with what was detected, what was done and what the re-check showed. The morning read is a short list of verified outcomes, not a guess about whether last night's fix held.
How it works
Auto-fix only the safe, repeatable cases
The auto list is short on purpose. Each entry is idempotent: running it twice is harmless. A failed build, a paused project, a stale deploy. Nothing that deletes, nothing that charges, nothing on a site I do not own.
Judgment calls go to my phone
Anything not on the safe list arrives as a Telegram message with an action attached. I tap approve and the executor runs the pre-scoped action. No dashboard, no login, no guessing what the right command was at 2am.
The bot never holds credentials
The internet-facing Telegram bot only writes an approval row to a table. A scoped executor on the server reads that row and does the work with its own keys. Compromise the bot and you get a queue, not access.
Boundary-gated
Only mapped repos and projects are eligible for automatic fixes. Anything outside the map is notify-only. Production sites I run for other people are never touched by this agent, by design.
Verified, not assumed
Every fix ends with a re-check against the provider. The heartbeat only goes green on the verified outcome, never on the attempt. A fix that did not actually land shows as a failure, not a success.
Results
- Failed builds on mapped repos get fixed and verified without me
- Provider alerts stopped living in an inbox and now arrive as one Telegram line with an action
- Zero new credentials on the internet-facing surface: the approval flow reuses an existing phone relay
- Heartbeat goes green only on the verified outcome, never on the attempt
- Same pattern later extended to a 'Requires my input' inbox on my dashboard
What this means for your business
Safe things fix themselves. Decisions come to a human. That split is the whole design. It applies far beyond hosting: refunds under a threshold, contract renewals, content republishing, anything where most cases are routine and a few need a person. If your team is the alert queue for your own systems, happy to grab a call to see what could fix itself and what should stay a one-tap decision.
Tools
- Python
- Vercel API
- Supabase
- n8n
- Telegram
- Claude Code
- Cloud server
Skills
- Infrastructure Automation
- Incident Response
- Self-Healing Systems
- AI Agents
- Human-in-the-Loop
- DevOps Automation
- Business Process Automation
- AI Integration
Questions
Can an AI agent safely fix a broken deployment?
Yes, for a defined set of failures on repos you have mapped. The agent clones the repo, lets the model fix the build error, pushes and then verifies the new deploy is green against the provider. If verification fails it reports a failure, it does not claim success.
How do you let a bot act without giving it your credentials?
Split it in two. The bot that talks to the internet can only write an approval row. A separate executor on the server, with its own scoped keys, reads that row and does the work. The bot never sees a credential, so a compromised bot gives an attacker a queue, nothing more.
What should an automation never do without a human?
Anything irreversible, anything that spends money and anything outside the boundary you mapped for it. Those become one-tap approvals on the phone. Everything on the auto list has to be safe to run twice.
How fast does it react to a failure?
The APIs are polled every 15 minutes and provider emails are picked up as they arrive. A broken build is usually fixed and verified before I would have opened the email. The log tells me in the morning what happened overnight.