Schedule icon
Request icon
Return icon
Switch icon
Log icon
SlackIncomingWebhook icon

AssemblyAI Transcription Error Sentinel

List recent AssemblyAI transcripts every hour, submit nothing, and alert Slack when speech-to-text errors cross your limits or jobs get stuck.

Categories
AI

Call recordings, meeting notes, podcast pipelines and voice-agent logs that go through AssemblyAI fail one transcript at a time: a storage bucket starts returning 403 for the audio URL, a recorder switches to a codec that cannot be decoded, a file has no audio track, or the account runs out of balance. Each job ends with status: error and an error string, the webhook that should have delivered the text never fires the way the app expects, and the gap shows up days later as empty call summaries. This blueprint turns a scheduled, read-only call to the AssemblyAI API into a transcription health gate: io.kestra.plugin.core.http.Request lists recent transcripts, one jq query computes the error rate, the most common error and the number of stuck jobs, and the result routes to a quiet log or a Slack alert.

How it works

  1. list_transcripts (io.kestra.plugin.core.http.Request) calls GET /v2/transcript?limit=200 with the API key in the Authorization header, which returns the most recent transcripts, newest first. It is a read: no audio is submitted and nothing is deleted. Retries cover short network blips, and allowFailed plus allowFailure keep an API error from aborting the flow so it can be reported instead.
  2. summarize_transcripts (io.kestra.plugin.core.debug.Return) first guards for a missing or non-200 response (UNREACHABLE). Otherwise one jq query keeps transcripts whose created time falls in the lookback window, computes the share of finished ones (completed or error) that ended in error, groups them by error text, and counts jobs still queued or processing that were created more than stuck_minutes ago. With at least min_transcripts finished, a rate at or above critical_error_rate is CRITICAL and one at or above warning_error_rate is WARNING; any stuck job is also WARNING; fewer finished transcripts is LOW_VOLUME; otherwise HEALTHY.
  3. route_by_errors (io.kestra.plugin.core.flow.Switch) branches on that classification: HEALTHY and LOW_VOLUME log quietly, WARNING posts a Slack note, CRITICAL and UNREACHABLE page Slack. A defaults fallback logs anything unexpected.
  4. log_audit_result (io.kestra.plugin.core.log.Log) writes one audit line per run with the HTTP status and the full summary.
  5. The flow-level errors block pages Slack if the flow itself fails, and the hourly_check trigger runs at 25 minutes past every hour, shipped disabled: true.

What you get

  • An hourly, read-only check of speech-to-text with no custom scripting and no extra plugin to install.
  • A status output (HEALTHY / WARNING / CRITICAL / LOW_VOLUME / UNREACHABLE) other flows can gate on, for example to hold call-summary jobs or resubmit failed audio once the cause is fixed.
  • Slack messages with the error rate, the number of stuck jobs and the most common error text, which usually names the cause (unreachable URL, unsupported file, no speech).
  • An audit line on every run, separate from Slack.

Who it's for

  • Contact centres, sales-call and meeting tools that transcribe recordings with AssemblyAI.
  • Media and podcast teams running batch transcription in Kestra.
  • Engineers who own a voice pipeline and want to hear about broken audio before customers do.

Why orchestrate this with Kestra

AssemblyAI reports each transcript's outcome on its own, through polling or a webhook. Kestra turns a plain, read-only list call into a scheduled, typed classification with retries, a failure path and an execution history, so a rising error rate or a stuck queue becomes one clear signal, and the status output lets your transcription flows react automatically.

Prerequisites

  • An AssemblyAI account with an API key from the dashboard.
  • A Slack incoming webhook for the WARNING, CRITICAL, UNREACHABLE and flow-failure alerts.

Secrets

  • ASSEMBLYAI_API_KEY: the API key of the project whose transcripts you want to watch.
  • SLACK_WEBHOOK: Slack incoming webhook used for every alert branch and the flow-failure alert.

In Kestra OSS, secrets are supplied as environment variables prefixed SECRET_ and base64-encoded, for example SECRET_ASSEMBLYAI_API_KEY=$(echo -n 'xxxxxxxx' | base64), and read back with {{ secret('ASSEMBLYAI_API_KEY') }}. Use the Enterprise secrets backend for encryption at rest and access control.

Quick start

  1. Submit a few transcripts of public audio files, plus one with an unreachable URL to produce an error.
  2. Add ASSEMBLYAI_API_KEY and SLACK_WEBHOOK as secrets.
  3. Run the flow manually with a low min_transcripts and compare the counts and error text in the logs with the transcript history in the dashboard.
  4. Enable hourly_check.

How to extend

  • Follow page_details.prev_url to read further back when you transcribe more than 200 files in the window.
  • Use the EU host (api.eu.assemblyai.com) if your project is in the EU region.
  • Pass status=error and created_on to build a daily list of failed transcript IDs to resubmit.
  • Store the last status in a KV store and alert only when it changes.

Inputs

  • lookback_hours: type INT, default 6.
  • warning_error_rate: type FLOAT, default 3.0 (percent).
  • critical_error_rate: type FLOAT, default 10.0 (percent).
  • min_transcripts: type INT, default 20.
  • stuck_minutes: type INT, default 60.

Outputs

  • status: one of HEALTHY, WARNING, CRITICAL, LOW_VOLUME, UNREACHABLE.
  • Example path: {{ fromJson(outputs.summarize_transcripts.value).top_error }} for the most common error.

Links

Pitfalls

  • Only the 200 most recent transcripts are read; high-volume projects need paging or a shorter window.
  • The window compares the created timestamp as a UTC string; if your account shows another time zone, widen lookback_hours a little.
  • Very long files can legitimately take a while; raise stuck_minutes if you transcribe multi-hour recordings.
  • The list only covers the last 30 days of transcripts, and deleted transcripts are not returned.
  • This flow only reads; it never submits, deletes or resubmits a transcript.
See How

New to Kestra?

Use blueprints to kickstart your first workflows.