DeployAngel

DeployAngel answers one question after every deploy--is this release working in production, or did it quietly break something?

Most deploy problems that get past CI don't raise an exception. A callback fires in the wrong order, a webhook stops arriving, a scheduled job skips a run, a route gets slower. Error trackers see nothing because nothing errored. DeployAngel catches these by comparing each release with the last one it cleared, per route and per job, using fixed rules with explicit sample sizes. There is no health score, and the optional AI investigation only explains a failure after the rules have found it.

Every release gets one of three outcomes. Cleared, with a report of what was exercised, what wasn't, and what is still being watched. Failed, naming the routes or jobs involved, the changed files most likely behind it, and the last good release. Not cleared yet, saying exactly what evidence is missing. A quiet app or an after-hours deploy waits for real traffic instead of passing on too little data.

The agent sends counts and latency histograms only, never request bodies, parameters, or cookies, and never makes a network call in a request path. DeployAngel never sends traffic to your app and never rolls anything back. Verdicts are available on the dashboard, by email and Slack, through a signed webhook, and to coding agents through a CLI, an MCP server, and CI exit codes, so a deploy pipeline or an agent can wait on the result and a person makes the final call on anything it flags.

Agents are open source under the MIT license for Rails, Hanami, Sinatra, Django, FastAPI, Flask, and ASP.NET Core. Deploys are detected automatically on Heroku and GitHub Actions, or registered with a one-line deploy hook anywhere else. DeployAngel works alongside Sentry, Honeybadger, AppSignal, and similar tools rather than replacing them.