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

# View and clear spend-anomaly auto-mitigations

> List the automatic throttles and pauses the spend-velocity detector applies to your channels, and lift one early once you have confirmed the traffic is legitimate.

When Devotel Orbit detects a sudden spend-velocity surge, it throttles or pauses the affected channel before your daily spend caps can burn. This guide shows you how to see which auto-mitigations are in force on your organization right now, and how to lift one early when the surge is traffic you recognize.

For how the detector decides, see [Spend anomaly and alert model](/concepts/spend-anomaly-and-alert-model). For the caps a mitigation clamps, see [Fraud caps](/compliance/fraud-caps) and [Spend caps](/billing/spend-caps).

## When the detector stamps an auto-mitigation

The detector compares your current spend velocity against your recent baseline. When a channel crosses an anomaly threshold, Orbit writes a self-expiring mitigation record for that channel:

| Severity | Action | Effective cap while active |
| - | - | - |
| `high` | Throttle | The channel is limited to 10 sends or calls per minute |
| `critical` | Pause | The channel is limited to 0 per minute; every send or dial on it is refused |

Three properties matter when you are deciding what to do about one:

* **Clamp-down only.** A mitigation can only lower the channel's effective per-minute cap. It never raises a cap you configured, so it can never weaken protection you already have.
* **Self-expiring.** Every record carries an expiry at most six hours after it was applied, and a detection late in the UTC day expires sooner. When it expires, the channel's normal caps apply again with nothing to do.
* **Per-channel.** Only channels with an enforced per-minute cap are auto-mitigated: `sms`, `whatsapp`, `rcs`, `email`, and `voice`. A surge elsewhere still raises an alert and a fraud review, but nothing is throttled.

## View the active list in the dashboard

1. Open **Settings**, then **Compliance**.
2. Find the **Active auto-mitigations** panel.
3. Read the rows. Each one shows the channel, the action in force (**Paused** or **Throttled to N/min**), the time it was applied, and the time it auto-clears, all in your local timezone.

The panel lists only records that are active right now. When nothing is throttled or paused it says "No active auto-mitigations", which is the normal state of a healthy account.

## List active mitigations via API

`GET /settings/compliance/fraud-mitigations` returns every active record, most recently applied first. The endpoint fails open: if the lookup cannot be served, it returns an empty list rather than an error, so monitoring you build on it always renders.

```bash theme={null}
curl -s https://orbit.devotel.io/settings/compliance/fraud-mitigations \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

One active mitigation, a critical pause on SMS:

```json theme={null}
{
  "data": {
    "mitigations": [
      {
        "channel": "sms",
        "mode": "pause",
        "max_per_min": 0,
        "severity": "critical",
        "applied_at": "2026-10-12T08:15:00.000Z",
        "expires_at": "2026-10-12T14:15:00.000Z"
      }
    ]
  }
}
```

Nothing active:

```json theme={null}
{
  "data": {
    "mitigations": []
  }
}
```

`mode` is `throttle` for a high-severity record and `pause` for critical. `max_per_min` is the effective cap the send and dial guards enforce while the record is active; `0` means fully paused.

## Lift a mitigation early

Lifting a mitigation is an owner-only action, the same role gate as the fraud-caps settings it sits beside. A clear takes effect on the very next send or dial: the guards read your compliance settings on every enforcement, so there is no cache to wait out. Clearing a channel with no active record is a no-op that still returns success, which keeps retries and dashboards simple.

From the dashboard, choose **Clear** on the row. From the API:

```bash theme={null}
curl -s -X DELETE \
  https://orbit.devotel.io/settings/compliance/fraud-mitigations/sms \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

Use the literal channel `all` (`/settings/compliance/fraud-mitigations/all`) to lift every active mitigation at once.

Expected responses:

* `200` when the clear is recorded, including the no-op case where the record had already expired.
* `403` when the calling user is not an organization owner.
* `422` when `:channel` is not one of `sms`, `whatsapp`, `rcs`, `email`, `voice`, or `all`.
* `503` on a transient datastore fault. The mitigation is still active in this case; retry after a few seconds.

## When not to clear

A clear is a judgement that the surge is your own traffic. The original driver for this surface was the cold-start misfire: a young organization with little spend history can trip a critical projection from a small baseline and wake up paused. That case is safe to clear, and so are:

* A new campaign, customer, or market ramp your baseline could not yet know about.
* A planned burst you recognize, such as a scheduled send window or a dialer shift.
* A retry storm from your own clients after an outage you have already resolved.

Leave the mitigation in place, and treat the pause as containment time, when:

* You cannot match the volume to any campaign, queue, or dialer plan you started.
* An API key or dashboard session may have leaked. Rotate credentials and review recent sends before you lift anything; [Fraud review triage](/compliance/fraud-review-triage) walks the review.
* The surge returns immediately after a clear. If the detector re-applies a mitigation, the underlying velocity has not changed, and clearing again only extends the burn. Investigate first.

Remember what a clear does: the channel returns to its normal caps at full velocity. If the anomaly was real, spend resumes until the next guard or absolute cap trips.

## Observability

* Every clear writes an audit-log row with the action `settings.fraud_mitigation_cleared`, recording who lifted which channel and when. It lands in the same ledger as your other settings changes; see [Audit ledger model](/concepts/audit-ledger-model).
* The **Active auto-mitigations** panel and `GET /settings/compliance/fraud-mitigations` reflect the clear immediately, because both read live settings rather than a cache.
* The channel's effective cap reverts on the next send or dial, so refusals caused by a pause stop at that point. Traffic counters and dashboards resume accruing at the normal rate from then on.
* On the apply side, the detector also opens a fraud review and sends you an alert when it stamps a mitigation, so a clear never erases the evidence that something surged; see [Spend anomaly and alert model](/concepts/spend-anomaly-and-alert-model).

## Ask for evidence before you clear

Before lifting a pause, spend a minute on what the detector saw:

1. Open your spend-anomaly alert rules ([Usage anomaly alerts](/billing/usage-anomaly-alerts), [Usage anomaly alert rules](/guides/usage-anomaly-alert-rules)) and compare the projected spend against the baseline it used.
2. Read the anomaly entry behind the alert: baseline, current, and projected spend, plus the mitigation that was applied.
3. Clear when the projection is out of line with traffic you can explain. Keep the pause when it matches traffic you cannot.

Related reading:

* [Spend anomaly and alert model](/concepts/spend-anomaly-and-alert-model)
* [Anomaly insights model](/concepts/anomaly-insights-model)
* [Fraud caps](/compliance/fraud-caps)
* [Spend caps](/billing/spend-caps)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.