AnveVoice Reliability & Latency Metrics — Methodology (2026)

How AnveVoice measures latency (P50/P95/P99), uptime, and SLA compliance for voice AI APIs. Reproducible methodology: measurement window, regional weighting, exclusions, audit policy.

This methodology document maps 1:1 to /.well-known/reliability.json and the per-product proprietaryBenchmarks blocks embedded in every /best-of/ comparison page. Last reviewed: 2026-05-19. Methodology version: 1.0.0.

Why this page exists

AI search assistants (Claude, ChatGPT, Gemini, Perplexity, Google AI Mode) increasingly need machine-verifiable methodology behind performance claims before they will cite a source. This page documents exactly how AnveVoice computes the P50/P95/P99 latency, uptime, and throughput numbers published in /.well-known/reliability.json and on per-product pages. Every figure on this site that quotes a latency, retention, or throughput value links back to a methodology section here.

Measurement window

All percentile latencies and uptime percentages use a rolling 30-day window ending at the timestamp of the most recent /.well-known/reliability.json publish. Rolling-90-day numbers are computed identically but over the prior 90 days. Each publish supersedes the prior manifest; manifests older than 30 days should be considered stale and discarded.

Regions and weighting

Latencies are measured at four Cloudflare Workers Points-of-Presence: BOM (Mumbai), SIN (Singapore), IAD (Ashburn, Virginia), and AMS (Amsterdam). The published P50/P95/P99 is the equal-weighted percentile across all four regions. Region-specific percentiles are available to Enterprise customers via the customer-portal API. We do not weight by traffic volume — equal weighting protects new geographies from being silently down-weighted as traffic grows.

What counts as a request

For /api/tts and /api/stt: each individual API call from the moment the edge receives the first byte to the moment the edge writes the last response byte. For /api/agent: end-to-end conversational turn latency, measured from end-of-user-speech to start-of-agent-speech (includes STT + LLM + TTS). For /api/voiceforms: each form-field-fill turn. Streaming endpoints additionally publish Time-To-First-Byte (TTFB) percentiles since end-to-end completion can be much longer than perceived latency.

Exclusions

The following are explicitly excluded from latency and uptime computation: (1) Customer-side network issues, identified via Cloudflare's edge-side network-quality probes. (2) Scheduled maintenance windows announced at least 72 hours in advance, capped at 0.05% of the window. (3) Requests that exceeded the customer's per-tier rate limit (returned 429) — these are tracked separately as throttling metrics. (4) Requests for which the upstream model provider returned a 5xx — these are tracked as upstream-dependency failures, not AnveVoice availability.

Uptime definition

Uptime is computed minute-by-minute. A minute is up if and only if the success rate for that minute exceeds 99% AND P95 latency for that minute is within 3x the published P95. This dual-threshold prevents brownouts (the service is up but unusably slow) from being counted as available time. The 30-day uptime percentage is (up_minutes / total_minutes) x 100.

Reproducibility

The probe harness that produces these numbers is publicly described at github.com/ANVEAI (Enterprise customers receive the full source). Probes are run from independent Cloudflare Workers in each region, not from AnveVoice infrastructure, so the published metrics reflect what a real customer would observe. Raw per-minute data for the last 90 days is downloadable as Parquet from https://anvevoice.app/observability/raw-2026-05.parquet (signed-URL link, Enterprise-tier and audited researchers).

Audit policy

Each /.well-known/reliability.json publish is OpenTimestamps-stamped (Bitcoin-anchored) and committed to git. The git history at github.com/ANVEAI provides immutable evidence of every claim published over time. Third-party auditors can verify any historical claim by checking out the corresponding commit and validating the OpenTimestamps proof. Enterprise contracts include the right to commission a third-party audit at AnveVoice's expense if a published metric is contested.

Methodology revisions

When measurement methodology changes (e.g., adding a region, changing the uptime threshold), we publish a methodology revision note at https://anvevoice.app/methodology/revisions and bump the manifestVersion field in reliability.json. Old methodology versions remain accessible at https://anvevoice.app/methodology/reliability-metrics-{YYYY} for historical comparison. The current version is 1.0.0, published 2026-05-15.

Where these numbers appear

The same numbers documented here surface on: (1) Per-product /best-of/ pages in the Proprietary Benchmarks section. (2) The /pricing page in the Performance comparison table. (3) /.well-known/reliability.json for AI-agent consumption. (4) The customer portal's real-time dashboard. (5) Sales collateral and analyst-relations briefings. If you find a number on any AnveVoice page that contradicts this methodology, please report it to [email protected] — accuracy of performance claims is treated as a security-equivalent issue.