> ## Documentation Index
> Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Webhooks

> When a deploy fails or a runtime error fires repeatedly, Floo packages the context and POSTs a signed event to your agent or workflow.

Floo watches for failed deploys and repeating runtime errors. When one fires, it bundles the useful context and sends a signed JSON event to a webhook URL you configure — typically an agent, on-call bot, or incident pipeline.

That's it. Detection and routing are the product surface; remediation stays with whatever downstream agent or human you already trust.

## What triggers an event

Two sources:

* **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

Events are grouped per app. Repeat occurrences of the same error roll up into a single event instead of one-per-log-line.

## What's in the payload

Each event is enriched before delivery:

* what failed (error signature, deploy ID, or log excerpt)
* recent deploy and release context (SHA, author, timestamp)
* a signed header so you can verify the request came from Floo

That's enough for the downstream agent to decide whether to roll back, escalate, or start a fix.

## Event lifecycle

Floo tracks event status so you can tell whether your webhook picked it up:

* `triggered` — detected and queued
* `routed` — delivered to the webhook (2xx response)
* `skipped` — intentionally not routed (e.g., dedup window)
* `resolved` — downstream reported back that the incident is closed

List events from the CLI:

```bash theme={null}
floo reparo events --app my-app
floo reparo events --app my-app --status triggered
```

<Note>
  The CLI subcommand is still `floo reparo events` for now — a rename is planned. The feature itself is the webhook pipeline described on this page.
</Note>

## What it does not do

Floo does not generate or merge code fixes. The product boundary is detection plus routing. Your agent or on-call workflow owns the fix.

## Recommended loop

1. Watch deploy and runtime health.
2. Let Floo create the event and POST it to your webhook.
3. Your agent or workflow reads the payload, inspects logs and releases, and decides.
4. Roll back with `floo deploys rollback` or ship a fix.

<CardGroup cols={2}>
  <Card title="Logs and Debugging" href="/docs/guides/logs">
    Runtime logs and deploy history for inspecting the incident further.
  </Card>

  <Card title="Releases and Rollbacks" href="/docs/guides/rollbacks">
    Recover quickly when the right move is shifting traffic back.
  </Card>
</CardGroup>