[Voice] [Trouble accepting Inbound Calls] [PROD 1]

Update timeline

1. monitoring Feb 20, 2026, 10:01 PM UTC

   Kustomer has implemented an update to address an event affecting inbound Voice calls in PROD 1 & 2 that caused inbound calls to drop before getting answered by an agent. Our team is currently monitoring this update to ensure the issue is fully resolved. Please expect further updates within the next 30 minutes, and reach out to Kustomer support at Email or Chat if you have additional questions or concerns.

2. investigating Feb 20, 2026, 10:21 PM UTC

   Kustomer is aware of an event affecting Voice conversations that may cause inbound calls to not be accepted properly in the system. Our team is currently working to identify the cause of this issue in an effort to implement a resolution. Please expect additional updates within the next 30 minutes, please reach out to Kustomer Support via Chat or Email for any further questions or updates.

3. investigating Feb 20, 2026, 10:53 PM UTC

   Kustomer is continuing to investigate an event impacting Voice conversations that may cause inbound calls to not be accepted properly within the system. Our engineering team is actively working to identify the root cause and implement a resolution as quickly as possible. We will provide another update within the next 30 minutes or sooner as more information becomes available. If you have any urgent questions or need assistance, please contact Kustomer Support via Chat or Email.

4. identified Feb 20, 2026, 11:08 PM UTC

   Kustomer is aware of an issue affecting inbound call acceptance in our PROD1 environment where inbound calls were not properly being accepted in the system. Our team has identified the cause of the issue within the code and are actively working on a fix to restore system behavior back to normal. Please expect additional updates within the next 30 minutes, and reach out to Kustomer Support at Email or Chat Channels if you have additional questions or concerns.

5. monitoring Feb 20, 2026, 11:33 PM UTC

   Kustomer has implemented an update to address an event affecting Voice conversations in PROD 1 that caused inbound calls to be dropped when trying to accept calls. Our team is currently monitoring this update to ensure the issue is fully resolved. If your agents are continuing to experience this issue please have them refresh their browser to apply the fix. Please expect further updates within the next 30 minutes, and reach out to Kustomer support at Email or Channel if you have additional questions or concerns.

6. resolved Feb 21, 2026, 12:01 AM UTC

   Kustomer has resolved an incident affecting Voice in PROD 1 that caused inbound calls to drop after being initially accepted. To remediate the issue, our team rolled back a recent code change to a previously stable version, which successfully resolved the error. After thorough monitoring, we have confirmed that all impacted services are fully restored. If any agents continue to experience issues, please have them refresh their browser to ensure the fix is applied. If you have any additional questions or concerns, please reach out to Kustomer Support via Email or Chat.

7. postmortem Mar 02, 2026, 04:53 PM UTC

   ## Summary On February 20, 2026, a frontend change intended to improve performance unintentionally disrupted call setup in our Voice experience. As a result, agents could see an incoming call and click accept/decline, but audio would not connect and calls would time out. We rolled back the change and then deployed an additional fix to make startup more reliable and prevent recurrence. ## What happened When the Voice widget starts, it needs to receive a small set of configuration settings \(including feature-flag values\) from the main app before it can route and connect calls correctly. A pre-existing timing edge case meant that, in some cases, that initial configuration could be sent before the Voice widget was fully ready to receive it. Historically, the widget would receive the same configuration again shortly afterward, which masked a state issue. The performance change reduced those repeated configuration sends \(which is normally a good optimization\). But because the widget sometimes missed the first configuration during startup, it could start with incomplete settings and fall back to legacy call-routing behavior. In that fallback mode, calls could appear answerable in the UI but fail to fully connect audio. ## Root cause A performance optimization changed how/when configuration settings were delivered during Voice widget startup. Combined with a pre-existing startup timing edge case, some sessions did not receive the required configuration in time and fell back to legacy call-routing behavior, preventing audio from being bridged correctly. ## Timeline * 3:04 PM ET: Frontend change deployed * 4:38 PM ET: Reports received that calls could not be answered \(accept/decline visible, no audio\) * 4:44 PM ET: Initial rollback attempt of an unrelated change did not resolve the issue * 4:50 PM ET: Incident communication initiated via status page * 6:24 PM ET: Frontend change reverted/rolled back * 8:47 PM ET: Reports continued for some agents * 10:31 PM ET: Identified that affected sessions could persist without a browser refresh due to cached UI state; refresh/new session restored correct behavior * Saturday 9:00 AM ET: Confirmed reports that calls were successfully connecting ## Lessons / improvements * Harden Voice widget startup so required configuration can’t be missed during initialization. * Add automated smoke/E2E coverage for core Voice call flows \(answer/connect audio\) to detect regressions before production. * Improve safeguards and monitoring around call-connect failures to reduce time-to-detect and time-to-mitigate.