> ## 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. # Troubleshoot the automatic security pause after unusual spend activity > A send or dial returns 'temporarily suspended by an automatic security pause after unusual spend activity' — see what wrote the pause, lift it early from the fraud-mitigations surface, and tell it apart from a spend cap or an insufficient-balance refusal. # Troubleshoot the automatic security pause When Devotel Orbit detects a sudden surge in spend velocity on your organization, it throttles or pauses the affected channel before a day's budget can burn. While a critical pause is active, every outbound send or dial on that channel is refused with one of the messages below. This page covers what wrote the pause, how to lift it early, and how to tell it apart from the other gates that stop outbound traffic. ## The error text Voice refusals read: > Voice calling is temporarily suspended by an automatic security pause after unusual spend activity. Messaging refusals name the paused channel at the start of the sentence (SMS, WhatsApp, RCS, or email): > SMS sending is temporarily suspended by an automatic security pause after unusual spend activity. Only the paused channel carries this wording; your other channels keep their usual responses. The wording is itself the diagnostic: an ordinary rate cap reads differently (`Voice call rate limit exceeded: N calls/min`, `SMS rate limit exceeded: N messages/min`), so the phrase "automatic security pause" tells you the spend-velocity detector is involved, not a cap you configured. ## What tripped it The spend-velocity detector compares your current spend against your recent baseline. When a channel crosses an anomaly threshold, Orbit writes a temporary mitigation into your organization's fraud settings (`settings.fraud.auto_mitigation.`) that clamps the channel's effective per-minute cap: | Severity | Action | Effective cap while active | | - | - | - | | `high` | Throttle | 10 sends or calls per minute; low-volume traffic still flows | | `critical` | Pause | 0 per minute; every send or dial is refused with the messages above | Three properties define the pause: * **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 returns to its normal caps with nothing to do. * **Clamp-down only.** The mitigation can only lower the effective cap. It never raises a cap you configured, so it cannot weaken protection you already have. * **Per-channel.** Only `sms`, `whatsapp`, `rcs`, `email`, and `voice` carry an enforced per-minute cap, so only those channels are paused. A surge elsewhere still raises an alert and a fraud review without throttling. Every pause also opens a fraud review and sends you an alert, so there is a record of what the detector saw. See [Spend anomaly and alert model](/concepts/spend-anomaly-and-alert-model). ## Lift the pause early If the surge is traffic you recognize, lift the mitigation before it expires. Lifting is an owner-only action. 1. Open **Settings**, then **Compliance**, and find the **Active auto-mitigations** panel. Each row shows the channel, the action in force (**Paused** or **Throttled to N/min**), and when it auto-clears. 2. Choose **Clear** on the paused channel. From the API: ```bash theme={null} curl -s https://orbit.devotel.io/settings/compliance/fraud-mitigations \ -H "Authorization: Bearer $ORBIT_API_KEY" 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. A clear takes effect on the very next send or dial: the guards re-read your fraud settings on every enforcement, so there is no cache to wait out and nothing to restart. Clearing a channel with no active record is a no-op that returns success. Do the judgement work before you clear. If you cannot match the volume to a campaign, queue, or dialer you started, or an API key may have leaked, rotate credentials and review recent sends first; clearing in that case only extends the burn. [View and clear spend-anomaly auto-mitigations](/guides/compliance-spend-anomaly-mitigations-self-serve) walks the full view-list, clear, decide loop, including when not to clear. ## Not a spend cap, not a balance problem Three gates stop outbound traffic for three different reasons, and the refusal text tells them apart: * **Automatic security pause (this page)** — the wallet is funded and the caps you configured are untouched; a temporary mitigation written by the detector is clamping one channel. The refusal names the "automatic security pause". * **A policy spend cap** — a daily or campaign ceiling you configured tripped. The refusal is a `429` spend-cap code, not the pause wording, and raising the ceiling is the fix. See [Spend-cap refusals](/troubleshooting/spend-caps-hit). * **Insufficient balance** — the wallet pre-flight could not cover the estimate hold. The refusal is `INSUFFICIENT_BALANCE` (402); top up or let auto-top-up fund the wallet. See [INSUFFICIENT\_BALANCE (402)](/troubleshooting/insufficient-balance). The tell for the pause: it trips while your balance reads fine and no cap you configured changed. ## When to escalate Clear the pause yourself when the projection is out of line with traffic you can explain. The classic case is a young organization whose small spend baseline makes a legitimate first campaign look like a surge; that clear is safe. Escalate to support when: * The mitigation re-arms immediately after a clear even though the traffic is planned and legitimate. * The detector keeps re-pausing the same channel on consecutive days after cold-start clears. Include in the ticket: * Your organization (tenant) id. * The paused channel and the timestamp of the first refusal. * The exact refusal text. * The active mitigation record for the channel (the `GET /settings/compliance/fraud-mitigations` output, the `settings.fraud.auto_mitigation` payload), which carries the applied and expiry timestamps and the severity that wrote it. ## See also * [View and clear spend-anomaly auto-mitigations](/guides/compliance-spend-anomaly-mitigations-self-serve) * [Spend anomaly and alert model](/concepts/spend-anomaly-and-alert-model) * [Spend-cap refusals](/troubleshooting/spend-caps-hit) * [INSUFFICIENT\_BALANCE (402)](/troubleshooting/insufficient-balance) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.