A pay-as-you-go account bills in real time and reconciles at month end. Anything that burns faster than your traffic plan expects — a misconfigured loop, a leaked API key, a toll-fraud probe, a sender hitting a DLR drought — shows up on the meter long before it shows up on an invoice. The earlier an operator sees the divergence between "what we meant to spend" and "what the ledger says we spent," the cheaper the fix. This post covers where Devotel Orbit's usage-and-delivery anomaly surface lives, how its detector classes split spend-side from inbound-side signals, and how to drill from a single detector raise down to the raw ledger row and the per-day trendline that tells you whether the raise is a spike or a habit.
Why spend anomalies matter on pay-as-you-go
Flat-rate and committed-minute pricing absorb surprises until reconciliation. Pay-as-you-go does not — the wallet is a live balance and every message, minute, and model token debits it as traffic runs. Three failure shapes make that more than an accounting nicety.
First, an operational bug can scale cost superlinearly: a retry loop that fires on every transient error, or an AI agent whose conversation histories get longer every turn, burns against the wallet at a rate that has nothing to do with how much business the traffic brings. Second, abuse and fraud target exactly the channels priced per unit — toll-fraud routes toward premium international terminators, SIM-swap and account-takeover flow shows as burn that bypasses your campaign tooling. Third, delivery quality has a cost side too: when a destination starts failing delivery receipts, you pay for attempts that never reach anyone.
None of these announce themselves as "spend." They raise as a detector event in the telemetry the platform already streams. What was missing was one forensic surface where every such raise lands, classified into the scopes an operator actually triages. That surface is the anomaly ledger.
Where the detector lives: Insights → Anomalies
Open Insights → Anomalies (/insights/anomalies) in the dashboard. The page streams off the same forensic ledger every detector in the platform already writes to — spend-velocity, toll-fraud, suspicious-campaign, and the rest — refreshed on a sixty-second cadence in lockstep with the API cache, so the number you see during an incident is never more than a minute stale.
The top strip answers the triage questions in order: how many raises are in the window, how many are still open, how many sit at high or critical severity, and the most recent detection time. Every figure can be read split by scope or in aggregate, and a scope filter (all, wallet, webhook/inbound) scopes the whole page.
Detector classes — wallet spend vs webhook and inbound scope
The ledger classifies each raise into one of two scopes, and the split is the page's organizing principle.
Wallet (spend) scope covers detectors whose signal is a burn-rate channel: SMS, voice, fax, and the per-unit-priced traffic that debits the wallet. A spend-velocity spike, an IRSF/toll-fraud pattern on a premium route, a suspicious-campaign burst — all of these land in the wallet scope because the cost of ignoring them lands on the wallet. When you triage a wallet raise, the question is "is this burn authorized traffic, or burn we should cut?"
Webhook/inbound scope covers the inbound-facing detectors: webhook delivery failures, inbound routing anomalies, API-key geo anomalies, and the detectors that fire on traffic you receive or endpoints you expose rather than traffic you send. Their blast radius is reliability and exposure, not direct cost — but a webhook endpoint misconfigured to accept anything also tends to become a spend problem one hop later, so both scopes share one ledger.
The scope split also respects the boundary the platform enforces on scope definitions themselves: outbound (MT) voice and messaging exit only through Devotel's own softswitch, and inbound-only providers stay inbound-only — so "wallet scope" and "webhook/inbound scope" are a clean partition of traffic direction, not a licensing distinction.
Drill from detector raise → raw ledger row → trendline
The page runs as one drill-down loop.
Detector raise. The summary strip or the trendline flags a raise on a scope. Click the scope filter — wallet or webhook/inbound — and the ledger below narrows to that scope's rows.
Raw ledger row. The ledger lists every detector raise in the window as a raw row: the detector category, the severity and current triage status, the channel the raise attached to, the detection timestamp, and the summary the detector emitted. That row is the forensic record — it carries the ledger entry the detector wrote at raise time, so an operator reads the evidence itself rather than a rolled-up aggregate. Triage status moves from open to resolved directly on the row, so the ledger doubles as the team's queue.
Per-day trendline. Above the ledger, a per-day chart buckets raises by scope across the window. One scope climbing while the baseline holds tells you the raise is ongoing, not a one-off burst; both scopes spiking on the same day points at a shared cause (a deployment, a campaign, an integration change). The trendline is what turns "we had an anomaly" into "this detector has been firing since Tuesday."
Alerting routing patterns
A detector raise in the dashboard is only useful when it reaches the person holding the pager. Three routing patterns cover most teams.
In-app severity gate. Keep high and critical raises routed to the on-call operator in-app — the scope badges and severity variant on each row make the noise/signal cut visible at a glance, and the status column keeps resolved work out of the queue.
Threshold rules on usage signals. On Insights → Usage alert rules (/insights/usage-alert-rules), define threshold rules on the usage signals that move the wallet — daily spend, month-to-date projection, per-agent conversation depth — and let only the threshold breach page, while the anomaly ledger remains the forensic archive. The LLM spend cost governor post walks the same pattern for AI budgets; the same structure extends to the wallet scope here.
Programmatic polling. The ledger endpoints behind the page — by-scope totals, time series, and history — are exposed on the Insights API, so teams that run their own incident channel can poll the sixty-second window and route raises into their on-call tooling with the scope and severity fields as routing keys.
Pick the pattern per severity: on-call paging for high/critical wallet raises, daily digest for open webhook/inbound rows, and the trendline review on a weekly cadence for the slow-drift detectors that never breach a threshold.
Frequently asked questions
What is the anomaly ledger in Devotel Orbit?
It is the Insights → Anomalies page: one dashboard over the forensic ledger every detector in the platform already writes to. Each detector raise appears as a raw ledger row — category, severity, triage status, channel, and summary — classified into wallet (spend) scope or webhook/inbound scope, with a per-day trendline over both.
What is the difference between wallet scope and webhook/inbound scope?
Wallet scope carries detectors on burn-rate channels — the traffic that debits the wallet as it runs, such as SMS and voice. Webhook/inbound scope carries inbound-facing detectors: webhook delivery failures, inbound routing anomalies, and raises on traffic you receive or endpoints you expose. The split matches how operators triage: wallet raises are a cost question, inbound raises are a reliability and exposure question.
How fresh is the data on the anomalies page?
The page refetches on a sixty-second cycle, matched to the API's sixty-second cache, so a raise is visible within about a minute of the detector firing.
Can I get anomaly alerts outside the dashboard?
Yes. The underlying ledger endpoints — by-scope totals, timeseries buckets, and history rows — are available on the Insights API, so you can poll them and route raises into your own incident channel using the scope and severity fields as routing keys.
How does this relate to the LLM spend cost governor?
The cost governor enforces a budget on AI model spend, downshifting model routing near the cap. The anomaly ledger is detection across every detector class, AI and telecom alike — it surfaces the raise and the evidence whenever usage or delivery diverges from the pattern. The two pair as enforcement plus detection: the governor bounds the one cost line that scales with conversation depth, the ledger watches everything else.