Kustomer Status Page

Jul 30, 2026 · resolved Jul 30

# **Summary** On July 30, 2026, the draft text editor on Kustomer’s Timeline product experienced degraded functionality in certain user workflows. Impact included sporadic cursor behavior, text erasure, and issues with copying and pasting text and shortcuts. # **Root Cause** This issue was introduced by a change to the editor that was not fully caught before release. Due to misalignment in our QA process our pre-release validation did not adequately cover the real-world editing patterns affected by this change. Furthermore, this misalignment contributed to a delay in Kustomer’s understanding of the incident's resolution status. # **Timeline** ## **Jul 30, 2026** **11:12 AM ET:** The editor change was deployed **12:27 PM ET:** Kustomer Technical Support escalated the incident to Kustomer’s OnCall process, notifying Engineering immediately. **12:34 PM ET:** Kustomer Engineering identified the issue and completed a rollback **12:51 PM ET:** Internal testing incorrectly confirms that the issue has been fully resolved, due to some customers reporting the issue no longer presented itself **1:29 PM ET:** Continued reports of issue are received from customers who did not receive the full resolution rollout **1:34 PM ET:** Discovery made that  the rollback did not fully deploy to resolve the issue. Kustomer Engineering makes additional change to ensure resolution **2:01 PM ET:** Corrective change deployed, and fix is confirmed # **Lessons/Improvements** Kustomer Engineering maintains a robust CI/CD process, and a multi-environment release process designed to prevent issues of this nature. As part of our continual investment in these areas, we have identified the following action items: * Ensure that our internal pre-production environments align with our customer-facing experience, including but not limited to the editor experience, so that issues of this nature are caught earlier in development * Complete an audit of our automated CI/CD process and test coverage of major features, removing any gaps that are identified

Jul 26, 2026 · resolved Jul 26

## Summary On July 25, 2026, some customers experienced elevated platform latency affecting messaging, conversation updates, routing, voice, and other customer-service workflows. Customers may have seen messages remain in a sending state, delayed inbound or outbound messages, slower page and API responses, delayed routing or assignment, and intermittent voice-call delays. The incident was caused by an unusually large burst of background data-processing activity. This created a sudden increase in demand on shared platform infrastructure. Automatic scaling added capacity, but it could not absorb the burst quickly enough to prevent degradation in dependent workflows. We restored service by increasing available capacity, reducing the rate of the initiating workload, and carefully processing delayed work while monitoring platform health. ## Impact * **Customer effect:** Intermittent platform latency; delayed inbound and outbound messaging; slower conversation and API updates; delayed routing or assignment; and intermittent voice-call delays * **Duration:** Customer-visible degradation began at approximately 5:22 PM ET. Service initially recovered at approximately 7:31 PM ET, but degradation later recurred. Broad platform performance was restored and the incident was resolved at 10:30 PM ET. * **Scope:** The incident affected a subset of customers within one production environment. We did not identify corresponding customer-facing degradation in other production environments. ## Timeline * **Approximately 5:22 PM ET:** Processing latency and message backlogs began increasing. * **6:51 PM ET:** The incident response team began coordinated investigation and recovery. * **Approximately 7:00–7:23 PM ET:** We identified affected processing paths and began carefully recovering delayed work at controlled rates. * **7:31 PM ET:** Additional capacity had come online, customer-facing performance had materially improved, and the incident was initially resolved while monitoring continued. * **8:28 PM ET:** The incident was reopened after renewed reports of intermittent degradation. * **Approximately 8:38 PM ET:** Investigation confirmed that messaging, routing, channel, and voice symptoms shared the same underlying platform dependency. * **Approximately 9:52 PM ET:** We reduced the rate of the initiating background workload to protect customer-facing traffic. * **10:08 PM ET:** Monitoring confirmed that workload pressure had fallen substantially and platform health continued improving. * **10:30 PM ET:** After continued monitoring confirmed recovery, the incident was resolved. * **After resolution:** Recovery of remaining delayed work continued at controlled rates under monitoring. ## Root cause A burst of high-volume background data-processing activity generated more downstream work than shared platform infrastructure could safely absorb over a short period. Automatic scaling responded and added capacity, but capacity was added incrementally and did not come online quickly enough for the size and speed of the burst. While the platform was catching up, increased request latency and timeouts affected customer-facing workflows that depended on the same infrastructure. ## Resolution We restored platform performance by: * Increasing available capacity and improving the rate at which additional capacity could be added. * Reducing the rate of the initiating background workload. * Recovering delayed work at controlled rates to avoid creating another traffic spike. * Continuing monitoring after customer-facing performance returned to expected levels. ## Preventative actions We are taking the following actions to reduce the likelihood and impact of recurrence: * Add stronger limits and backpressure controls for high-volume background operations. * Improve the speed at which shared infrastructure scales during sudden traffic increases. * Improve isolation between background processing and latency-sensitive customer workflows. * Expand alerting for rapid backlog growth, resource pressure, and unusual workload patterns. * Strengthen controlled recovery procedures for delayed work. * Expand burst-load and failure-recovery testing for shared platform services. ## Current status Platform performance returned to expected levels, and the initiating workload remained controlled. We continued monitoring service health and the recovery of delayed work after resolution.

Jun 25, 2026 · resolved Jun 25

## **Summary** On June 25, 2026, some customers were unable to send outbound WhatsApp replies from within Kustomer. The issue affected reply sending for a subset of WhatsApp channel configurations, which disrupted agent workflows and prevented some automated outbound messages from being sent through the same path. The issue was identified and resolved the same day. Service was fully restored, and the platform is operating normally. ## **Root cause** A change released earlier that day introduced stricter validation in the outbound WhatsApp reply flow. For a subset of supported channel configurations, valid sender values were incorrectly rejected before messages were sent. This caused reply attempts in those configurations to fail. The issue was limited to specific WhatsApp channel setups and did not affect all WhatsApp traffic equally. ## **Timeline** * **June 25, 2026, approximately 22:12 UTC** — Reports began coming in that outbound WhatsApp replies were failing for some customers. * **Shortly after detection** — Investigation confirmed the issue was tied to a recently released validation change in the outbound reply flow. * **June 26, 2026, approximately 01:07 UTC** — A fix was deployed and reply sending was restored. ## **Lessons and improvements** * Validation changes for messaging flows now require broader test coverage across supported channel configuration variants before release. * Additional safeguards are being added to reduce the risk of valid outbound requests being rejected. * Monitoring and regression checks around outbound messaging paths are being strengthened to detect similar issues more quickly.

Jun 12, 2026 · resolved Jun 12

## Summary On June 12, 2026, customers using WhatsApp through Kustomer experienced a service event that prevented some outbound messages from being delivered to end users. During the event, messages could appear as sent in Kustomer before final delivery was confirmed by WhatsApp. Service recovered the same day, and affected messages from the incident window were successfully reprocessed. ## Root cause This event was caused by a disruption in WhatsApp Business Platform services operated by Meta. While that disruption was active, Kustomer was unable to complete delivery for some outbound WhatsApp messages and queued affected messages for retry after the upstream service recovered. ## Timeline * **10:14 AM EDT** — Customer reports led to investigation of outbound messaging behavior. * **10:34 AM EDT** — Meta reported high disruptions affecting WhatsApp Business Platform services. * **1:45 PM EDT** — Reprocessing of queued messages began as upstream recovery progressed. * **2:32 PM EDT** — Meta reported recovery for the remaining affected WhatsApp services. * **4:07 PM EDT** — Active message sending was healthy again. * **4:34 PM EDT** — Messages from the incident window had been successfully reprocessed. ## Lessons and improvements * We are improving monitoring and alerting for queued WhatsApp messages so degraded delivery is identified earlier. * We are documenting a safer reprocessing procedure for queued WhatsApp traffic to reduce the chance of retry-related rate limiting during recovery. * We are reviewing backlog-handling procedures to make recovery more predictable when an upstream provider disruption occurs. At this time, system health for WhatsApp message delivery through Kustomer is stable.

Jun 9, 2026 · resolved Jun 9

**Summary** On June 9, 2026, customers experienced delays in chat message delivery and related real-time updates for a portion of the morning. The issue was caused by a third-party service event affecting the infrastructure used to propagate real-time messaging updates. Service recovered the same morning, and current system health is stable. **Root cause** A third-party real-time messaging provider experienced elevated latency and intermittent publish failures in one of its regions. That disruption delayed delivery acknowledgements and other real-time updates in Kustomer. Messages continued to be stored successfully, but some updates were not reflected immediately in the client until the external service recovered or the client refreshed. **Timeline** * **9:05 AM EDT** — Customer impact began, including delayed chat message delivery and stale real-time updates. * **9:45 AM EDT** — The third-party provider reported active latency affecting its service. * **9:48 AM EDT** — The provider reported mitigation and recovery. * **Shortly after recovery** — Real-time behavior returned to normal and monitoring confirmed stability. **Lesson/improvements** * We added additional monitoring tied to the third-party provider's public service health signals so similar service events can be identified faster. * We are improving alerting around real-time messaging errors to reduce time to diagnosis. * We are continuing to review operational signals to better distinguish external service issues from internal platform issues.

Is Kustomer down right now?

No — Kustomer is up. All systems operational as of Aug 19, 9:41 PM UTC.

What is Kustomer's current status?

Kustomer: All Systems Operational. Alert24 checks Kustomer's status page continuously and can notify you the moment it changes.

How do I get alerted when Kustomer goes down?

Alert24 monitors Kustomer and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.