API status
How to check whether the QuillAI API is healthy, how we communicate incidents, and what to monitor on your side during beta.
Health check
There is no dedicated /health endpoint yet. The cheapest way to check that both the API gateway and the auth layer are up is to hit GET /v1/me — it's the same call the dashboard uses.
curl -I https://api.quillhub.ai/v1/me \
-H "Authorization: Bearer $QAI_KEY"A 200 OK means the API is healthy. A 401 means your key is bad (not an outage). A 5xx means we have an issue on our side — check our announcements channel before retrying.
What "up" means
QuillAI is a handful of moving parts. When we say the API is up, we mean all of these are healthy:
- API gateway — Accepts requests at api.quillhub.ai, authenticates keys, and enqueues jobs.
- Transcription workers — Pull queued jobs, call the upstream transcription provider, and write results back.
- Storage — S3-compatible object storage for uploaded audio and generated subtitles.
- Billing — Decrements points on completion and blocks new jobs when your balance is exhausted.
Known degradations
During beta we don't have a public incident feed yet. When something breaks we reach you through two channels:
- Email to the account owner on file for anything that affects your data or billing.
- A Telegram announcements channel, @quillai_status, for real-time status updates (placeholder — the channel may not be live yet; we'll email you the link when it opens).
Uptime target
There is no formal SLA during beta. We're targeting 99.5% monthly availability and expect degraded modes in the early days as we scale workers and tune the pipeline. Once we leave beta we'll publish a binding SLA and backfill historical uptime numbers.
Reporting an issue
If a request fails and you think it's our fault, grab the request_id from the failing response and send it to [email protected]. It's the fastest way to pin down what happened — we can trace the exact request through our logs. See Errors.
Monitoring on your side
- Point a simple uptime check (BetterStack, Pingdom, UptimeRobot — anything works) at GET /v1/me once a minute with a test key.
- Alert only after 3 consecutive 5xx responses — single 5xx bursts happen during deploys and don't warrant a page.
- Never alert on 4xx — those are user errors (bad key, malformed body) and always mean your side, not ours.
Coming soon
Later in beta we'll ship a public status page at status.quillhub.ai with per-component uptime history and a subscribe button, plus an optional webhook that fires when component status changes so you can wire it straight into your incident tooling.