How ThunderPhone keeps agents reliable: status, self-detection, and testing like software

A voice agent is production software that answers the phone. Its reliability cannot rest on a launch-day demo or a single promise. It has to be observed, tested, corrected, and tested again throughout its life. ThunderPhone's approach starts with a public status page, accessed 2026-09-01, and extends through automatic production issue detection, pre-deployment regression testing, live human oversight, operational alerts, and verifiable webhook delivery.

That machinery covers different stages of the same lifecycle:

This page describes ThunderPhone's own reliability controls. For a vendor-neutral framework, see how to evaluate the most reliable voice AI. Reliability is also broader than accuracy; the evidence and limits for that separate question are covered in the most accurate voice AI guide.

Public status and uptime history

ThunderPhone publishes current service status and uptime history at status.thunderphone.com, accessed 2026-09-01. The same destination is available through thunderphone.com/status.

This page deliberately does not copy an uptime percentage or incident count into static prose. Those figures change over time, while the status page remains the source of truth. Buyers and operators can inspect the public history directly rather than relying on a number that may have become stale since publication.

A status page answers whether the shared service is operating normally. It cannot, by itself, tell a customer whether one agent followed the wrong policy, mishandled a tool result, or gave an incorrect answer. That is the job of the production issue system.

Production self-detection turns calls into issue patterns

ThunderPhone analyzes calls and can automatically raise an issue when it detects that something went wrong. User-reported issues enter the same system, so automatically detected and manually identified failures can be investigated together. The ThunderPhone Issues guide, accessed 2026-09-01, documents this workflow.

Repeat occurrences are grouped into patterns instead of becoming an unstructured queue of isolated reports. For example, fifty occurrences of “the agent quoted the wrong hours” can appear as one pattern with its occurrence trend and affected calls. Each pattern carries a severity of Critical, Warning, or Info and a status of Open, Dismissed, or Resolved.

Resolution is not permanent bookkeeping detached from production. If a new occurrence matches a resolved pattern, the pattern reopens. That behavior matters because a prompt edit, knowledge change, or nearby configuration change can reintroduce a failure that appeared fixed.

The affected calls remain central to the investigation. “Fix with AI” studies those calls, forms hypotheses about the root cause, and drafts targeted prompt changes. The proposed changes appear as redline diffs for human review before anything is applied. Automation proposes; people approve. The system is designed to shorten the path from a production symptom to a reviewable correction without silently rewriting an agent.

Testing agents like software

Production detection is the feedback loop after callers encounter an agent. ThunderPhone also provides several layers for finding failures before a change reaches all callers. The complete process combines simulations, reusable real-call examples, release gates, CI integration, and controlled live experiments.

AI-caller simulations and scenario suites

An operator can run a one-shot AI-caller simulation, execute scenarios in parallel batches, or collect reusable scenarios into suites. These are billable real calls, and the launch flow shows the charge before a run. The Simulate a call guide and Test agents guide, accessed 2026-09-01, describe the testing workflow.

Simulations make repeatability possible. Instead of asking a colleague to improvise another demo call, a team can define the caller's situation and expected outcome, run the scenario again after a prompt change, and compare results. A practical testing plan is available in how to test voice agents.

Validation sets preserve real call behavior

A validation set freezes one real agent turn from a call as a reusable example. The saved case includes the conversation context, caller audio, the agent's actual behavior, and ground truth describing the correct behavior. It can be classified as Failure, Golden, or Manual:

• Failure preserves behavior that should not recur.
• Golden preserves known-good behavior that should continue working.
• Manual supports a case that requires an operator-defined evaluation.

The set can be replayed against the current draft without placing another call. This gives teams a focused regression check based on their own callers and operating conditions rather than a generic demonstration.

Validation cases also have lifecycle states. A case becomes Stale when the prompt has changed since the example was frozen, signaling that its expectation should be reviewed. A case can also become Incompatible when it can no longer run against the current configuration. The Validation sets guide, accessed 2026-09-01, documents these case types and states.

Release gates catch pass-to-fail transitions

A release-gate suite pins its scenarios and agent, sets a minimum pass rate, and compares subsequent runs with a baseline. When a scenario that previously passed begins failing, the run reports that transition as a regression. This is the voice-agent equivalent of preventing a software release from shipping when an established test breaks.

Suites can be wired into CI through organization API keys and the test-call.completed webhook. That lets a deployment workflow wait for test results and stop a change before it reaches production callers. See the Test agents guide, accessed 2026-09-01, and the definition of regression testing for voice agents.

Some changes still need production evidence. ThunderPhone's A/B experiments, accessed 2026-09-01, provide a controlled way to compare agent variants on live traffic rather than replacing one version everywhere at once.

Live human oversight

Pre-deployment tests cannot anticipate every live conversation. ThunderPhone's Live board lists every in-progress call with its agent, direction, caller, and ticking duration. Staff can join a call as a hidden, listen-only participant and coach the agent while the call is still underway.

That creates a human intervention path without requiring the staff member to announce themselves as another call participant. The capability is documented in Monitor live calls, accessed 2026-09-01.

Operational metrics, call evidence, and alerts

ThunderPhone's observability views track call volume, success rate, failures, and per-agent attribution. The calls behind each number remain available, connecting an aggregate change to the conversations that produced it. Every call leaves a transcript and graded call logs; recording is configurable, so a recording should not be assumed for every call. See ThunderPhone Observability, accessed 2026-09-01.

Alert rules watch those metrics and notify teams through email, Slack, or webhooks when a threshold is crossed. The documentation gives examples including success rate below 80% over the last day, more than 500 calls in an hour, and a test-suite regression. These are examples of configurable operational rules, not universal recommendations for every deployment. The appropriate threshold depends on the workflow and its normal traffic. See ThunderPhone Alerts, accessed 2026-09-01.

Together, observability and alerts close an important gap: dashboards support investigation, while notifications tell the team when to investigate.

Verifiable webhook delivery

Integrations also need a reliability boundary. ThunderPhone signs webhook requests with HMAC-SHA256 using a secret assigned to each endpoint. Consumers can verify the signature before trusting the payload.

Delivery is non-blocking and unsuccessful attempts use exponential-backoff retries. Per-endpoint secrets limit the verification boundary to the intended destination. Implementation details are in Verify webhook signatures, accessed 2026-09-01.

Honest boundaries: the workflow still matters

Platform controls cannot make an underspecified workflow reliable on their own. Customers still decide the prompt rules, knowledge, actions, transfer paths, testing coverage, and voicemail policy. Voicemail handling has three possible configurations: let the agent prompt decide, hang up, or leave a configured message. Those choices should be tested as deliberately as the main call path.

ThunderPhone's tools make these customer-controlled levers observable and repeatable: simulations exercise them, validation sets preserve important cases, release gates catch regressions, and production issues reveal gaps that escaped testing. Pricing for billable tests and production calls is covered in ThunderPhone pricing.

ThunderPhone is GDPR and HIPAA compliant, and customers remain responsible for configuring their workflows, data handling, recordings, and notices for their own obligations.

FAQ

Does ThunderPhone have a status page?

Yes. ThunderPhone publishes current service status and uptime history at status.thunderphone.com. The live page is the source of truth, so this guide does not freeze an uptime percentage or incident count in prose.

How does ThunderPhone catch failures?

It combines automatic call analysis with threshold alerts and human reporting. Call analysis raises issues, repeat occurrences are grouped into patterns, and new occurrences reopen resolved patterns. Separately, alert rules can notify email, Slack, or webhooks when call metrics or test results cross configured thresholds. The affected calls remain available for investigation.

Can I test changes before they go live?

Yes. AI-caller simulations exercise one-off scenarios, parallel batches, and reusable suites. Validation sets replay frozen real-call turns against a draft without another call, while release-gate suites compare results with a baseline and report pass-to-fail regressions. Suites can also be integrated into CI through organization API keys and the test-call.completed webhook.

Does ThunderPhone publish an SLA?

ThunderPhone's published materials describe the reliability machinery above and provide public status history, but they do not publish SLA terms. Ask sales about contractual terms for your deployment. For background on what an SLA covers, see service-level agreements.

Can a human intervene in a live call?

Yes. Staff can use the Live board to find an in-progress call, join as a hidden listen-only participant, and coach the agent during the conversation.

Sources and freshness

Everything on this page reflects ThunderPhone's published documentation and public status page, accessed 2026-09-01. Each capability links to its corresponding guide so readers can inspect the operating details directly. Status and documentation can change after publication; use status.thunderphone.com for current service state and the linked documentation for the current product behavior.