Status: Resolved
Call processing was delayed for some customers between the early hours of 30 July and 3 August 2026, after a core processing setting unexpectedly reverted to disabled overnight. We identified this and restored processing the same day, and cleared the resulting backlog by 3 August. No data was lost. We're still investigating exactly why the setting reverted, and how to catch a similar slowdown internally sooner next time.
Some customers experienced delayed call processing overnight and into the following morning, meaning newly completed calls took longer than usual to become available for review. No call data was lost at any point.
30 July, around midnight: A core processing setting that controls call transcription unexpectedly reverted to a disabled state. This wasn't yet noticed internally.
30 July, 09:09: The delay was reported and the incident was declared.
30 July, 09:22: The reverted setting was identified and re-enabled, and calls began processing again.
3 August, 07:52: The processing backlog had cleared.
3 August, 10:34: Incident resolved after confirming no further reports.
Call processing depends on a setting that controls whether call transcription is active. Overnight, this setting reverted to disabled without any deployment or configuration change that we've been able to identify as the trigger, and calls stopped being processed as a result. We identified and corrected this once it surfaced, but we haven't yet established exactly why the setting reverted in the first place, and that investigation is ongoing.
We re-enabled the reverted setting as soon as it was identified, which allowed processing to resume.
We're actively investigating why the processing setting reverted, so we can rule out a recurrence rather than treating the same-day fix as closing the question. Separately, we're looking at adding internal alerting on call processing delays, so a similar slowdown would be caught directly rather than depending on being told.
