Burst streams: capacity priced by the day.
$10
a stream-day, only on spike days
Every voice fleet has two sizes: the ordinary day and the spike. Committed streams price the first; burst streams price the second, $10 a stream-day, only on the days the spike is real, with a cap you set.
The mechanics
- Traffic past your committed streams spills over automatically, callers hear an answer, not a busy signal.
- Each burst stream bills $10 for that day only; a quiet day bills nothing.
- The dashboard cap is the control: set the maximum burst stream-days you will accept, and past cap the API refuses fast with a retryable 503 instead of surprising finance.
The break-even, stated
Burst is deliberately simple arithmetic: $10 a stream-day, counted only on days a burst stream actually speaks. No tier to negotiate and no minimum to commit, a spike you did not plan should not become a conversation.
table 01
One overflow stream, priced both ways
| Spike days / mo | On burst | A committed stream |
|---|---|---|
| 3 | $30 | $150 |
| 10 | $100 | $150 |
| 15 | $150 | $150 · break-even |
| 22 | $220 | $150 |
Where burst earns its keep
The workloads that spike by calendar, not by trend: a dubbing deadline, a course-wide re-narration, launch-day localisation, the 8 AM Monday wave, the end-of-quarter dialer push. This page is the mechanism they all lean on.
Notes
Do I have to enable burst?
It is a dashboard cap: set it to zero and traffic past your streams gets the retryable 503 instead of spilling. Set it high for storm season, low for the quiet quarter, the knob is yours.
Is a burst stream slower than a committed stream?
No, a burst stream is the same serving path with the same measured figures. Burst is a billing state, not a serving tier.
A key, one stream, your own script, nothing on it counted while you build.
Get a key, run your own script