Skip to main content

​
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.<channel>) that clamps the channel’s effective per-minute cap: 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.

​
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:
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 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.
  • 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).
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