Turn it on
Error routing is off until you point it at a URL. Configure it per app on the dashboard under App → Alerts → Error routing, or withPUT /v1/apps/{app_id}/reparo/config over the HTTP API:
There is no CLI command for this configuration.
floo events list is the
read-only view of what has already fired.
What triggers an event
- runtime errors, repeated error conditions surfaced in logs crossing the configured threshold
- failed deploys, a deploy that never goes live, rolled back, or exited non-zero
What’s in the payload
Each event carries:- what failed (error signature, deploy ID, or log excerpt)
- recent deploy context (commit SHA,
triggered_by, timestamp) X-Floo-EventandX-Floo-Appheaders, plusX-Floo-Signature(sha256=HMAC of the body) when a signing secret is set
Event lifecycle
Each event’s status shows whether your webhook received it:triggered: detected and queued for deliveryin_progress: delivery in flight or being retriedsucceeded: the webhook responded 2xxfailed: delivery failed permanently after retriesskipped: matched but suppressed (cooldown or rate limit)
What it does not do
floo does not generate or merge code fixes. Your agent or on-call workflow owns the fix.Recommended loop
- Watch deploy and runtime health.
- Let floo create the event and POST it to your webhook.
- Your agent or workflow reads the payload, inspects logs and releases, and decides.
- Roll back with
floo deploys rollbackor ship a fix.
Logs and debugging
Runtime logs and deploy history for inspecting the incident further.
Releases and rollbacks
Recover quickly when the right move is shifting traffic back.