Service status

What we monitor

ZentryVoice service status covers six components, each probed from outside the platform as well as from inside it. “Voice core” means the ability to place and receive a call on a practice number end to end: the Telnyx trunk, the Grandstream CloudUCM instance for the practice, and the inbound route between them. It is measured with synthetic test calls every minute per region plus the Telnyx call-quality webhooks (post-dial delay, MOS, packet loss) that stream into the Control Plane. A practice is considered degraded, not merely slow, when test calls fail or quality drops below the threshold for two consecutive minutes.

The other components are measured the same way: SIP registration (every PBX trunk and every desk phone must be registered; GDMS reports device status every 60 seconds), messaging (SMS delivery receipts from the practice number within 60 seconds), fax (T.38 send and receive on a test fax number, hourly), the practice portal (HTTPS checks from multiple regions every minute), and the Control Plane API that provisioning, webhooks and the live dashboards depend on.

• checkVoice core: synthetic calls each minute · Telnyx quality webhooks · trunk registration to sip.telnyx.com:5061
• checkSIP registration: CloudUCM trunk state and GDMS device heartbeats every 60 seconds
• checkMessaging: delivery receipts on outbound SMS from the practice number
• checkFax: hourly T.38 round trip and PDF archive write
• checkPortal: multi-region HTTPS checks, sign-in flow and live dashboard stream
• checkControl Plane API: webhook intake from Telnyx, GDMS, payments and e-signature

What 99.999% means

ZentryVoice targets 99.999% availability, “five nines”, for the voice core. Availability is the share of minutes in a year during which calls can be placed and received on practice numbers; five nines leaves 0.001% of the year, which is about 5.26 minutes of unplanned downtime in a year, or roughly 26 seconds a month. The target is measured on the voice core only, because that is what a front desk notices first, and because the carrier and PBX layers are the ones designed with redundant paths: Telnyx anchors calls in multiple sites, CloudUCM instances are backed up nightly, and a practice number can be re-pointed to a backup route from the Control Plane within minutes.

The portal, messaging and fax have a 99.9% target (about 8.8 hours a year), which reflects their dependence on third-party delivery networks and the fact that a message or fax that is delayed by minutes is still delivered. The targets are engineering commitments and are reported transparently in the portal; they are not a financial guarantee unless your order form includes a service-level credit schedule.

Maintenance windows

Planned maintenance that could affect a practice, such as PBX firmware rollouts, CloudUCM template updates or desk phone upgrades pushed through GDMS, is scheduled in a standing window from 2:00 AM to 4:00 AM in the practice’s local time zone, never in the Control Plane’s time zone. Each rollout is run as a tracked job: the PBX is backed up first, the change is applied, and the trunk registration to Telnyx is verified before the job is marked done. If verification fails, the change is rolled back from the backup automatically and an engineer is paged.

Most maintenance does not drop calls. Platform deploys to the portal and API are zero-downtime, and carrier-side changes are made on the Telnyx side without touching the trunk. When a window will interrupt service, for instance a PBX reboot that takes about 90 seconds, practice administrators receive an email at least 72 hours in advance, and the portal shows the window on the Support page. Practices with 24-hour operations, such as answering services or on-call lines, can ask support to move their window.

How we communicate during an incident

When monitoring detects a failure, the on-call engineer confirms it, opens an incident, and the status surfaces in two places within 15 minutes: a banner in the practice portal for every affected practice, and an email to practice administrators. Updates follow at least hourly until the incident is resolved, even when the update is only that we are still working on it. Updates say what is affected in plain terms (for example, “inbound calls to practice numbers in the Southeast region are failing”), what the workaround is if there is one, and when the next update is due.

1. 1DetectSynthetic checks, carrier webhooks or a support ticket flag the problem; the on-call engineer is paged within one minute.
2. 2Confirm and classifyThe engineer reproduces the failure and sets severity: critical (calls failing), major (one component degraded), minor (cosmetic or delayed).
3. 3NotifyWithin 15 minutes of confirmation: portal banner for affected practices and an email to administrators, with the next update time.
4. 4MitigateRe-route numbers, fail over the trunk, roll back a deploy, or restore a PBX from its last backup; the workaround is posted as soon as it is live.
5. 5ResolveService is verified with the same checks that detected the failure, and the all-clear is posted.
6. 6ReportA written post-incident report is published in the portal within 5 business days.

Post-incident reports

Every critical or major incident gets a written post-incident report within 5 business days of resolution, posted to the Support page in the portal and emailed to administrators of affected practices. The report states the timeline in the practice’s local time, the root cause in plain language, the customer impact (which components, which regions, for how long), what we changed to stop it from recurring, and whether any PHI was involved. If an incident is also a security incident, the BAA and privacy notification clocks start from discovery, and the report says so explicitly rather than waiting for the engineering write-up.

Where to see live status

This page does not show live numbers, and that is deliberate. Component health varies by practice (your region, your PBX instance, your numbers), so a single public gauge would be either misleading or vague. Live status for your practice, with the current state of each component, open incidents, scheduled maintenance and the last 90 days of incident history, is shown in the practice portal under Support. Administrators can also subscribe to email notifications per component. ZentryVoice staff see the same data in the Control Plane, which is also where incidents are opened and updated, so the portal always reflects what the engineers are seeing.

infoSign in to the practice portal and open Support to see live status for your practice. If you cannot reach the portal, call the priority support line printed on your welcome sheet.