Observability

Every synthesis request that hits the gateway is recorded as operational metadata. This guide is what you can see, where, and how to plug it into your own monitoring without storing sensitive audio inputs or outputs.

Request logs

The dashboard's Speech Gateway -> Request Logs view shows recent synthesis requests with:

• Request ID
• Timestamp
• Provider, model, voice ID
• Character count of the input
• Output duration (ms) and audio size
• Latency breakdown — gateway and upstream
• Status — success, moderation block, provider error, timeout
• Moderation decision and reason type when a ruleset evaluated the request
• Safe provider options, filtered to an allowlist

For conversations, the parent request is shown alongside per-turn child events so you can see which turn's provider was slow.

The same operational data is available through the Logs API.

What's not in the logs

By design, request logs do not contain:

• The synthesis text.
• The output audio bytes or signed URLs derived from it.
• Provider error response bodies (which sometimes echo input).
• Your provider keys or your Speechbase API key (only key IDs and last-four).
• User PII beyond what's strictly required for abuse detection.

This is deliberate. See Logging hygiene for the rationale and the operational metadata allowlist.

Usage analytics

The dashboard homepage surfaces:

• Current month's request count and projected month-end.
• Spend on the platform fee and your remaining prepaid/free credits.
• Active voices and storage used.

Detailed usage and spend controls are in the Settings -> Billing view.

Mapping logs back to requests

Every API response carries an X-Request-Id header. Persist it in your own application logs alongside the operational metadata you record. Then in the dashboard you can find the matching log entry by Request ID.

const res = await fetch("https://api.speechbase.ai/v1/audio/speech", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SPEECHBASE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ mode: "voice", voiceId, text }),
});
log.info({
  speechbaseRequestId: res.headers.get("x-request-id"),
  status: res.status,
  voiceId,
  charCount: text.length, // count, not the text itself
});

Forwarding to your own observability stack

There's no first-class log forwarding yet. If you need request data in your own SIEM or warehouse, capture it client-side: every synthesis call goes through your service, so you already have the latency, status code, and metadata.

Capture an allowlist of operational fields per request. Don't capture the input text or the output audio bytes — those belong only in your application's hot path, not in observability storage.

Alerting

A simple SLO that catches most issues:

• Synthesis success rate — 2xx / total over a rolling 5-minute window. Alert if it drops below 99%.
• P99 latency — Speechbase attributes latency to gateway vs upstream in the log entry. Spikes in upstream latency are usually a provider incident; consider failing over to a backup provider for the duration.
• Moderation block rate — sudden spikes can indicate a bug in your upstream prompt that's emitting content moderation can't pass, not malicious users. Monitor for changes from your normal baseline.