The earlier usage-and-delivery anomaly post made the general case for a forensic anomaly ledger on a pay-as-you-go CPaaS. This one is the module map: Devotel Orbit ships four detection surfaces a buyer evaluating "delivery anomaly detection" or "agent cost monitoring" will actually touch, and each one answers a different operational question. Below we walk all four end-to-end — what each measures, where the thresholds come from, and what an operator does after the raise — then compare that against building your own detector on the per-MNO-delivery and route-quality exports.
The anomaly family on the platform
Four modules, four signal classes. They share one detection posture — tenant-set thresholds, in-app alert delivery — but each measures a distinct failure axis.
Usage & delivery anomaly ledger (Insights → Anomalies, /insights/anomalies). Every detector in the platform writes to one append-only ledger, and the page separates raises into two scopes: wallet (spend) — the burn-rate channels that debit the wallet (SMS, WhatsApp, email, RCS, voice, agent usage) — and webhook/inbound — phone-number and webhook-endpoint signals on traffic you receive. The summary strip counts open and high/critical raises over the window; below it, each detector raise sits as a raw row with category, severity, triage status, channel, and detection timestamp, and a per-day trendline buckets raises by scope. One scope climbing while the baseline holds means the raise is ongoing, not a burst.
Per-route DLR-drop detector (Insights → Deliverability, the route-DLR anomaly card). For every outbound SMS route — provider × destination country — it compares the last complete UTC day's delivery rate against a learned baseline width, computes a z-score, and flags a statistically significant drop before customers open tickets. The header badge collapses the snapshot to one of three tones: routes dropping, all routes healthy, or baseline building (when a route has too few qualifying baseline days to judge). Each row carries the current rate, the baseline mean and standard deviation, the drop in delivery points, and the sample size behind the judgment.
LLM/agent spend (Insights → LLM spend, /insights/llm-spend). AI cost broken down by agent, by model, and by feature channel (voice transcription, inbox agent-assist, knowledge-base retrieval), with hour- or day-granularity timeseries and a top-conversations list ranked by token cost. The overview card shows today's spend against the daily cap and month-to-date spend against a month-end projection; a budget form sets the monthly and daily caps, per-channel thresholds, and the alert percentage — plus an automatic model downshift that trips at a configured fraction of the cap. The cost-governor post goes deeper on the budget mechanics.
Per-operator route quality (Messages → Settings → Route quality). A composite health score per operator (MCC/MNC) built from delivery rate, latency percentiles (p50/p95/p99), the ack-without-receipt rate, and a grey-route suspicion flag. Operators band from healthy through degraded and poor to critical, with named factor penalties in the row explaining the score. Loopback probes run on a configured cadence per operator to keep the feed honest, and a manual "Check & notify" evaluation pages the in-app bell on each breached threshold.
The detection posture: thresholds you set, alerts delivered in-app
None of these thresholds are platform-mandated. The tenant sets them, and the surfaces above read them back.
Usage alert rules (Insights → Usage alert rules, /insights/usage-alert-rules) is the self-serve rule editor over three usage metrics — SMS delivery rate, outbound message volume, and spend. A rule picks a mode (threshold with a comparator and value, or anomaly-driven), a window in days, a cooldown between firings, and an enabled toggle; each breach lands in the in-app notification feed and is listed in the rule's event history with the fired value, with deep links back to the relevant surface. This is the posture tenant-owned alerting should take: the tenant defines acceptable traffic, the platform evaluates it on a schedule.
The LLM-spend budget form and the route-quality thresholds (minimum health score, maximum p95 latency, grey-route alerting, minimum volume before judging, severity) follow the same contract — the tenant's limits are saved in settings, and both surfaces evaluate against them. The anomaly ledger itself is detector-driven rather than threshold-driven: those raises arrive from the detectors, and the usage alert rules are how you graft tenant thresholds on top.
Signal to action: what an operator does next
A detection surface earns its place when each raise maps to a next step that is also done on the platform.
- Route DLR drop → quarantine the route or rotate the provider. A dropping route on the deliverability card means one provider × country pairing degraded. Reroute the affected destination to a healthy provider, or drain the route, while the baseline rebuilds; outbound traffic still exits only through Devotel's softswitch, so this is a routing decision, not an infrastructure change.
- Wallet-scope anomaly → freeze the burn. Open the ledger row, read the detector's own summary and the channel it attached to, then cut the loop — disable the campaign, rotate the leaked API key, or block the toll-fraud destination — and move the row from open to resolved in the same view.
- LLM spend breach → trip the budget, or let the downshift trip it. The per-channel threshold breach lands as a warning at the configured percentage of cap; the model downshift can automatically route to a cheaper model before the cap hits. Either way, the top-conversations list ranks the conversations burning the most tokens so an operator can bound conversation depth.
- Route-quality band drop → escalate with evidence, roll back an agent version, or fix the loop. A degraded or critical band names its penalty factors (latency, failure rate, grey-route suspicion) — enough to take to the operator as an evidence-backed escalation, and enough to rule out the operator and look at your own agent or campaign change instead.
Build-vs-buy, stated honestly
You can build all of this yourself. The per-MNO-delivery export and the route-quality scores are available on the API, so a team with a spare engineer and a metrics stack can poll the feeds, learn a baseline, compute z-scores, and page its own on-call channel. That path is real, and for one narrow signal — say, one delivery-rate threshold on one route — it can be the right call.
The honest cost comparison is in the parts that do not show up in the first sprint. A homegrown detector has to keep a baseline store, decide what a qualifying sample is, floor the standard deviation so a low-variance route does not z-spike on noise, handle the insufficient-data case without crying wolf, dedupe firings with a cooldown, route the alert, and keep all of that running. Then it has to do the same again for spend and for AI-token burn, and keep the thresholds in one place per tenant. The four modules above already ship each of those pieces with the export feeds they read from; the API remains open, so the build-your-own option stays available, but most teams buy back the engineer-quarter the plumbing would take and spend it on the routing decisions instead.
Frequently asked questions
What does the platform flag on its own?
Detectors raise events into the anomaly ledger automatically — spend velocity, toll-fraud patterns, suspicious campaign bursts, webhook and inbound anomalies — and the per-route DLR detector judges every route with enough qualifying baseline days against its learned baseline. No tenant configuration is required for these raises to appear.
What stays a tenant-owned control?
The thresholds. Usage alert rules (delivery-rate, volume, and spend), the LLM-spend budget caps and downshift trigger, and the route-quality health thresholds are all tenant-set and tenant-owned. The platform evaluates them and delivers the fires in-app; it does not pick the values, and it never reroutes or throttles your outbound traffic on its own.
Can I pull these signals into my own incident tooling?
Yes. The anomaly ledger endpoints (by-scope, history, timeseries), the per-route DLR snapshot, the LLM-spend endpoints, and the route-quality scores are all on the API, and usage alert rules accept an evaluate-now call. Polling teams use the scope and severity fields as routing keys.
How fresh are the signals?
The anomaly surfaces and the route-DLR card refetch on a sixty-second cadence matched to the API-side cache; route-quality scores refresh on a five-minute window; usage alert events list the fired value at evaluation time rather than a recomputed estimate.