Skip to content

A second vendor you have already integrated.

The expensive part of failover is not capacity, it is the integration you have not written yet. A committed stream is that integration, already tested.

How it works

  • You keep your primary vendor. Your committed streams sit behind our endpoint, integrated and tested, ready to take the traffic.
  • Cutover is a base URL change your code already handles. You exercise the failover path before the outage, not during it.
  • A stream carrying failover traffic serves at the same measured figures as any other stream, on the same production API, with nothing throttled.

listing 01

the integration you already have, pointed at a second base URL

const PRIMARY = "https://tts.your-current-vendor.example"
const FAILOVER = "https://tts.gandr.ai"  // integrated, tested

async function synthesize(req) {
  try {
    return await speak(PRIMARY, req)
  } catch {
    // same three surfaces, same request shape , 
    // the failover is the integration you already wrote
    return await speak(FAILOVER, req)
  }
}

Why teams skip failover, and why this is different

A second full fleet doubles your voice bill against an event measured in hours a year, so most teams skip it and hope. Here the second vendor is a stream you are already using and already paying for, which is why the readiness costs nothing extra.

Notes

Do I pay extra to hold capacity in reserve?

No. There is no separate reserve product. A committed stream is unmetered, so the same stream serves your normal traffic and your failover traffic without a second line on the invoice.

How do I test the failover path without an outage?

Point a canary share of traffic at our base URL on a schedule. The request shape is identical, so the test is a config change. An untested failover path is a hope, not a plan.

A key, one stream, your own script, nothing on it counted while you build.

Get a key, run your own script