Rolling out

Calling is the kind of feature users notice the moment it breaks, so it goes out the way any risky change does: to a few people first, with a way back that takes seconds.

Before the first user

• A per-user flag in your product decides whether a user gets Talkline calling. Talkline has no flag of its own; this one is yours.
• A kill switch turns it off for everyone at once, without a deploy. Flip it on purpose at the first ramp step, to know it works before you need it.
• Internal users first, for a week, making real calls on real networks.

The ramp

1 % of users, then 10 %, 50 %, 100 % — moving on only when the measures below look at least as good as what users had before. A user is on your previous calling path or on Talkline, never both at once.

What to watch

Measure	Where it comes from
Calls completed — answered calls that ended with a hangup rather than a failure	endReason in call.ended, or GET /v1/calls
Missed calls	call.missed deliveries ÷ call.ringing deliveries
Time to answer	answeredAt − ringStartedAt on each call (GET /v1/calls/{sid}); the full timeline is GET /v1/calls/{sid}/events
Reconnections that recovered	Your clients' own logs of connectionState: how often reconnecting returned to connected
Calls that dropped	media_failed, reconnect_timeout and transport_failure end reasons
Quality	The quality grades your clients log, per call

Compare against your previous calling path where you have one; otherwise, the first weeks set the baseline.

Who to call when

Your deployment's operator runs the servers. Report a failure with the time it happened, the identities involved, and the call sid (CS_…) or room sid (RM_…) — never a user's personal details, which Talkline does not have and does not need.