> ## 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. # Number health diagnostics console walkthrough > Read the per-number health surface — failed-call rate, DLR misses, trunk-abnormal counters, reputation tier, and the forecast — and decide whether to swap, wait, or reroute. # Number health diagnostics console walkthrough When a DID stops delivering, the first signal is not a carrier notice — it is a drift in the health counters the daily scheduler already collects. The per-number health surface surfaces that drift before it becomes a blocked campaign: a delivery-rate drop, a complaint-rate tick up, a DLR-miss spike, or an abnormal trunk counter that says the upstream route is degrading, not the number itself. This guide covers the **Numbers → \[select a number] → Health** surface in the dashboard: what each metric means, how the score-tier bands map to decisions, how to tell a number problem from a trunk problem, and when to swap, wait, or reroute. For the API that backs this surface, see [Number health, warming, and carrier reputation tracking](/numbers/health); for trunk-level diagnostics, see [SIP trunk health and connectivity diagnostics](/voice/sip-trunk-health-and-diagnostics). *** ## Where the health surface lives Open **Numbers** in the dashboard, select a DID from the list, and open the **Health** tab. The surface has two panels: 1. **Reputation score** — a 30-day rolling deliverability score with a tier badge (Excellent / Good / Fair / Poor / Critical / Unknown), the breakdown rates (delivery, failure, complaint), the minimum sample-size threshold, and the last-computed timestamp. 2. **Health trend & forecast** — a time-series panel that plots the score over a configurable window (30, 60, or 90 days) and projects it forward. It also flags step-change anomalies — a score dropping 12+ points between two ticks — which a slow slope would smear away. Both panels read from the same data source: the daily health-score scheduler that persists per-number aggregate counters. No live carrier call runs when you open the tab; every metric is a locally-stored snapshot refreshed on a daily cadence. For the fleet-wide view — which numbers across your entire inventory need attention first — use the reputation-alerts banner on the Numbers dashboard, fed by `GET /api/v1/numbers/reputation-alerts`. The per-number Health tab is the drill-down that tells you *why* a flagged number landed on that banner. *** ## What health telemetry is gathered per DID The daily scheduler computes five counters for every number that has sent outbound traffic in the rolling 30-day window: | Counter | What it measures | Why it matters | | - | - | - | | **Delivery rate** | Messages accepted by the carrier as a fraction of messages attempted. | A drop below 90 % usually means either a content filter has tightened or the number's registration has lapsed (10DLC, toll-free verification, or free-entry form). | | **Failure rate** | Messages rejected by the carrier with a definitive error code (undelivered, carrier block, invalid destination). | A spike against one number but not others on the same trunk points to a per-number reputation flag; a spike across every number on the trunk points to a trunk-level problem. | | **Complaint rate** | Messages the carrier classified as spam, opt-out, or abuse. | This is the hardest signal: a complaint rate above 1 % puts the number at risk of a carrier "Spam Likely" label. | | **DLR-miss rate** | Messages accepted by the carrier that never returned a terminal delivery receipt. | A DLR-miss spike on one number while peers on the same trunk are clean suggests the carrier is silently dropping that number's traffic — a quiet degradation that delivery-rate alone would miss. | | **Trunk abnormal counters** | Registration flaps, 5xx carrier responses, and timeout events tied to the trunk the number rides on. | These are the trunk-health signals the SIP trunk diagnostics page also surfaces; when they spike for one number but not its trunk peers, the degradation is per-number, not per-trunk. | The scheduler folds these counters into a composite **health score** (0–100) and assigns a **tier**: `excellent` (85+), `good` (70–84), `fair` (50–69), `poor` (30–49), or `critical` (under 30). Numbers under the minimum sample-size threshold return `tier: "unknown"` with no numeric score — there is not enough history to give a reliable signal. *** ## How to read a degraded signal and decide swap vs wait vs reroute When a number's tier drops to `poor` or `critical`, you have three choices. The right one depends on what the breakdown tells you. ### Decision tree 1. **Check the breakdown.** Open the Health tab and look at the three rate columns — delivery, failure, complaint. Which one moved? 2. **Cross-reference the trunk.** Open **Voice → SIP trunks → \[the trunk this number rides on] → Health** and compare. Are the trunk's peers also degraded? 3. **Decide.** | Signal | Trunk peers clean? | Action | Rationale | | - | - | - | - | | Complaint rate above 1 % | Yes | **Swap.** The number has drawn a carrier spam flag. Quarantine it, warm a replacement, and migrate traffic. | A flagged number rarely recovers; keeping it live risks the trunk's reputation. | | Failure rate spike, single number | Yes | **Swap.** The carrier has started rejecting this specific DID. | The same campaign content sending fine through a peer number confirms the problem is the number, not the content. | | Failure rate spike, multiple numbers | No | **Reroute** traffic to a different trunk provider, then investigate the trunk. | A trunk-wide failure-rate spike is a carrier-side degrade — reroute first, diagnose second. | | DLR-miss spike, single number | Yes | **Wait** one tick (24 h), then re-check. | DLR pipelines have transient gaps; a single-number miss often resolves on the next tick. If it persists two ticks, swap. | | DLR-miss spike, multiple numbers | No | **Reroute.** | A trunk-wide DLR pipeline outage means the carrier is accepting traffic but not returning receipts — your delivery-rate reads inflated. Treat it as a trunk incident. | | Score trending down slowly (slope \< 0.5/day) | Yes | **Wait** and tighten content. | A slow decline is usually a content-filter tightening, not a number block. Review the outbound template for trigger words, then re-check after one tick. If the decline continues, warm a replacement. | | Anomaly detected (step-change drop of 12+ points) | Yes | **Swap immediately.** | A step-change is the signature of a carrier flag landing between ticks — the number will be dead shortly. Quarantine it now and migrate traffic to a warmed replacement. | ### When to wait and re-check The daily scheduler runs once per 24-hour cycle. A single bad tick is not a trend. Wait and re-check when: * The DLR-miss rate spiked on one tick but the delivery and complaint rates are unchanged. * The failure rate moved by less than 5 percentage points and the number is still in `fair` or better. * The trend line shows `stable` (movement under 0.2 points/day) even though the current score is lower than you would like. ### When to reroute (trunk-level, not number-level) Reroute means keeping the number but pointing it at a different termination trunk — a carrier-level change, not a number replacement. Do this when the trunk-abnormal counters spike across every number riding that trunk. The SIP trunk diagnostics page (`Voice → SIP trunks → Health`) tells you whether the trunk itself is degraded; when it is, rotating the number does nothing — the next number on the same trunk hits the same failing upstream. Reroute first, then re-check the number health after the new trunk settles. *** ## Number intelligence vs voice SIP trunk diagnostics: which page for which signal Operators commonly confuse a per-number health signal with a trunk health signal because both surfaces show delivery and failure metrics. The table below disambiguates them. | Question | Go to | What you see | | - | - | - | | Is this *specific number* delivering well? | **Numbers → \[DID] → Health** | Per-number score, tier, breakdown rates, trend, forecast, and anomaly flags. | | Is this *SIP trunk* registered and reachable? | **Voice → SIP trunks → \[trunk] → Health** | Registration status, latency, step-by-step probe verdict, and a ranked list of trunks needing attention. | | Are the trunk's *peer numbers* also degraded? | **Numbers → \[DID] → Health** (compare), then cross-reference the trunk Health tab. | If multiple numbers on the same trunk show the same failure-rate spike, the trunk is the common cause. | | Which numbers across my *entire inventory* need attention? | **Numbers dashboard → reputation-alerts banner** | A ranked list of every monitored DID with a current flag, risk, or missing registration. | | Is a number likely to draw a spam label *before* it happens? | **Numbers → \[DID] → Health → Trend panel** (forecast), or `GET /numbers/:id/spam-likelihood`. | The projected tier and the early-warning spam-likelihood score with an ordered remediation playbook. | The rule of thumb: **if the Health tab on the SIP trunk page shows green but the number Health tab shows red, the problem is the number.** If both are red, the problem is the trunk — fix the trunk first, then re-evaluate the number. *** ## Worked examples ### Troubleshooting a degraded US 10DLC DID A US 10DLC number (`+1 415 555 0100`) shows `tier: "poor"` with a complaint rate of 1.8 % and a delivery rate of 82 %. The failure rate is 6 % and stable. 1. Open the number's Health tab. The complaint rate is above the 1 % threshold. 2. Open the SIP trunk Health tab for the trunk this number rides on. The trunk is `registered` with every probe step `ok`, and peer numbers on the same trunk show `good` or `excellent` tiers with complaint rates under 0.5 %. 3. **Decision: swap.** The number has drawn a carrier flag. Quarantine the number, order or select a warmed replacement from the same 10DLC campaign, migrate the dialer campaign and sender pools to the replacement, and retire the original. If you configured the closed-loop reputation remediation policy under **Settings → Numbers → Reputation**, this sequence runs automatically on the next daily tick. ### Cross-SIP compare vs the SIP trunk diagnostics guide A number shows `tier: "critical"` with a failure rate of 45 %. You suspect a trunk problem but are not sure. 1. Check the trunk Health tab: the trunk is `unregistered` with the `register` step `pending`. The SIP trunk diagnostics page tells you this is a NAT pinhole — the registrar did not answer the `REGISTER` within the probe budget. 2. Check peer numbers on the same trunk: every one shows `tier: "critical"` or `"poor"` with the same failure-rate spike. 3. **Decision: reroute.** The trunk is not reachable, so every number on it is failing. Switch the trunk's transport from `udp` to `tcp` (as the SIP trunk diagnostics guide recommends for NAT pinholes), or reroute traffic to a different trunk. Do not swap any individual number — the numbers are fine; the trunk is not. 4. After the trunk recovers, re-check the number Health tab. If the failure rate drops back to normal within one tick, no number action is needed. *** ## API surface The Health tab reads from two endpoints under `GET /api/v1/numbers`: * **`GET /api/v1/numbers/:id/health`** — the point-in-time health snapshot. Returns `score`, `tier`, `breakdown` (delivery / failure / complaint rates), `min_sample_size`, and `last_computed_at`. When the sample is too small, `score` is `null` and `tier` is `unknown`. * **`GET /api/v1/numbers/:id/health/trend`** — the time-series panel. Accepts `window` (30d / 60d / 90d), `bucket` (day / week), and `horizon_days` (1–60). Returns the per-period score array, the `direction` (improving / declining / stable), the `forecast` (projected score and tier), and any `anomaly` detection. Both endpoints are pure reads of locally-persisted daily snapshots — no live carrier call, no outbound voice or SMS path. For the full endpoint catalog — warming, reputation, spam-likelihood, branded-calling analytics, and the closed-loop remediation policy — see [Number health, warming, and carrier reputation tracking](/numbers/health). *** ## Tenant scope Every metric on the Health tab is scoped to your own numbers and your own outbound traffic. The daily scheduler computes counters from your tenant's message and call records; a number you do not own returns `404`, and a wrong number ID from another tenant is indistinguishable from a wrong ID in your own tenant — ownership is never leaked across tenants. *** ## See also * [Number health, warming, and carrier reputation tracking](/numbers/health) — the full API endpoint catalog. * [SIP trunk health and connectivity diagnostics](/voice/sip-trunk-health-and-diagnostics) — the trunk-level diagnostics surface. * [Number Intelligence dashboard](/guides/number-intelligence-dashboard) — the lookup console, metering, and spend caps. * [Number inventory and lifecycle](/numbers/lifecycle) — purchase, port, release. * [Number warming](/numbers/health#warming) — per-number 10DLC warming ramp. * [Closed-loop reputation remediation](/numbers/health#closed-loop-reputation-remediation) — automate the swap-and-retire pipeline. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.