When Warns is unreachable

The guard asks Warns for a decision before every payment. If the decision service cannot be reached, what happens next depends on the agent's mode and on the fallback rules you give the guard.

Unreachable means a network error, no answer within timeoutMs (2 seconds by default), or a server error. A rate limit is not an outage: it throws a PaymentBlockedError with the code RATE_LIMITED.

In Monitor mode

An agent in Monitor mode never stops paying because of Warns. If the service becomes unreachable, the agent keeps paying as it would have without Warns, and the guard reports those payments as soon as it reaches the service again, so they still show up in your dashboard.

The guard learns the agent's mode from the decisions it receives. A process that starts while the service is already unreachable has not received one yet, so until its first decision it follows the fallback rules below, like an agent in Protect mode.

In Protect mode

By default the guard fails closed: no decision, no payment. The call throws a GuardUnavailableError, and nothing is signed.

The simplest way to change that is in the dashboard: Settings, Workspace, When Warns is unreachable. Choose Allow small payments and an hourly amount. Every decision carries this choice, and the guard keeps the last one it received, so it applies from the agent's first payment after the change (SDK 0.4.0 and later).

To decide in code instead, pass fallback to the guard. It wins over the dashboard setting:

const guard = createGuard({  // ...  fallback: {    default: "closed",    rules: [{ maxUsd: 0.05, mode: "open_after_local_checks" }],    localBucket: { usdPerHour: 1 },  },})

What still applies during an outage

A payment let through on fallback still passes the checks the guard can do on its own: the asset must be USDC at its pinned address, the authorization window must stay under your limit, and the signer only signs that exact payment. What the guard cannot do without the service is compare against your history and your policies: price baselines, new or changed destinations, budgets.

Payments made on fallback are kept in memory, up to 100, and uploaded after the next answer from Warns, so your records have no gap. They show up in Transactions as approved by the SDK while Warns was unreachable. guard.flushFallbacks() uploads them on demand.