Having reviewed the documentation, terms of service, and public-facing marketing materials for Cartesia's voice synthesis API, I must concur with the implicit premise of the thread title: a formal, numerical uptime Service Level Agreement (SLA) appears to be conspicuously absent from the published legal and support pages. This is a significant omission for any service positioning itself for production workloads, particularly in the real-time audio streaming domain.
A standard SLA typically enumerates commitments across several dimensions, with uptime percentage (e.g., 99.9%, 99.95%) being the most common. It also defines:
* The calculation methodology (usually `(Total Minutes - Downtime Minutes) / Total Minutes * 100`).
* The scope of what constitutes "Downtime" (often limited to complete unavailability returning 5xx HTTP errors for a sustained period).
* The measurement window (monthly or quarterly).
* The service credits or remedies provided for breaches of the SLA.
My search through Cartesia's resources yielded the following:
* **Terms of Service:** Focuses on usage policies, IP, payment terms, and standard liability disclaimers. No SLA specifics.
* **Support/FAQ Pages:** Discusses best practices, technical integration, and how to contact support, but not guaranteed availability.
* **Pricing Page:** While pricing is tiered, no corresponding SLA tiers are mentioned alongside them.
This lack of transparency creates operational risk. For instance, consider a scenario where you are architecting a customer-facing application with synchronous voice generation:
```python
# Example of a potentially critical path in an application
try:
response = cartesia.synthesize(
text=user_query,
voice_id="premium_voice_123",
model="sonic-2024-10",
stream=True # Real-time streaming
)
# Stream audio directly to client
except cartesia.ApiError as e:
# What is the expected availability? Is this a frequent or rare event?
fallback_to_basic_tts()
```
Without a published SLA, it is impossible to formally assess:
1. The viability of Cartesia as a primary, dependency for a high-availability service.
2. The financial or service-level recourse during an outage.
3. How their infrastructure redundancy and deployment architecture (single-region, multi-region failover) supports uptime claims.
I would be interested in hearing from other users who have engaged with their enterprise sales teams. Often, formal SLAs are negotiated as part of custom enterprise contracts, but their absence from public documentation suggests a potential gap in their commitment to smaller-scale production users. For comparative analysis, most established cloud providers (AWS, GCP, Azure) and even many specialized AI-as-a-Service vendors publish their SLAs publicly, detailing both commitments and remedies.
Has anyone obtained a concrete SLA document from Cartesia, either through a sales channel or after a significant outage? Alternatively, has the lack of a defined uptime guarantee influenced your architecture decisions, perhaps leading you to implement more aggressive client-side retries, persistent connection pools, or a failover to an alternative TTS provider?
Great breakdown. I had the same experience digging through their docs last month when we were evaluating them for a campaign.
You're spot on about the real-time audio part - that's a big red flag. If you're stitching this into any kind of customer-facing flow and the voice just drops, the experience is broken. It's not like a delayed analytics ping.
I ended up asking their sales team directly. They gave me a verbal "we target five-nines" but refused to put it in writing, which tells you everything. We went with a provider that had a clear 99.9% SLA, even if the voices weren't quite as crisp.