When moderation is down

Last modified: 25 July 2026

Fail open, by default

If the moderation path does not answer — processor unreachable, overloaded, or timing out — voice chat keeps working, unmoderated. Utterances that could not be checked are skipped, and players carry on talking.

That is the shipped default and it is deliberate. A moderation outage silencing every player on the server is a worse failure than an hour of unmoderated voice.

moderation:
  fail-closed: false

The alternative

If your server cannot tolerate unmoderated voice at all, fail-closed: true mutes everyone while the processor is unhealthy and restores them when it recovers. It is a real setting, not a stub, and it is not the default.

Pick one on purpose. The startup log states which one is active.

Busy is not broken

The processor admits a bounded number of requests at once — roughly eight simultaneous in-flight on the reference 4-vCPU deployment. Past that it answers 503 processor_busy immediately instead of queueing, and the plugin treats that like any other unavailability: fail open, skip that utterance, keep the request budget for the next one.

Shedding beats queueing here. A queued utterance that arrives after the 2.5 second budget is worthless anyway. If you are seeing sustained busy responses, the fix is capacity, not a longer timeout.

Watching for it

/vs status reports processor health from the server side.
Timeouts appear in the server log with code=timeout.
A self-hosted processor answers /healthz; point your own monitoring at it.
Cloud service state is published on the status page.