Kobiton Inc Status Page

Mar 10, 2026 · resolved Mar 10

Per Apple Insider, "Apple's system status page for developer services lists an App Store Connect outage as being resolved, as of 6:06 PM Eastern. The webpage offers few details, but it says that all users of the service experienced a problem." https://appleinsider.com/articles/26/03/10/a-now-resolved-apple-server-outage-stopped-developers-from-verifying-apps

Jul 14, 2025 · resolved Jul 14

This incident has been resolved.

May 15, 2025 · resolved May 16

We have resolved the issue.

Mar 31, 2025 · resolved Mar 31

**1: What happened** A single `device-connector` pod in the US Prod cluster reached **100% CPU saturation** and stopped servicing gRPC traffic. Because the pod’s existing _gRPC_ health probe continued to return `OK`, Amazon EKS left the instance in the target group and the load balancer routed traffic to it. All requests that landed on that pod stalled, producing time-outs for a subset of customers. **2: Impact** * Device bookings, passcode processing, cleanups and other device administrative processing tasks were delayed. * Automation jobs that required an available device were blocked. * Manual testing sessions already in progress were **not** interrupted. * No data corruption occurred. **3: Timeline \(UTC\)** | Time | Event | | --- | --- | | 15:32 | First customer report of devices not returning to `Available` after end of session. | | 17:09 | On-call engineer identifies one pod pegged at 100% CPU. | | 17:52 | Evicted pod deleted. | | 17:57 | Devices return online. | | 18:12 | Devices launching successfully. Incident marked as `RESOLVED` | | 19:12 | 1-hour watch period passes with no recurrence. | **4: Root cause** A service that receives admin messages from individual device connect instances was responding to gRPC health probes so the pod remains healthy in EKS. However, the pod in EKS was not able to process new requests. Requests routed to the pod hang until they timeout after 30 seconds. **5: Immediate resolution** * Manually deleted the faulty pod; Kubernetes deployed a fresh replica. * Confirmed consumer and producer offsets were fully caught up; no message loss. **6: Follow-up / preventive actions** | Action | Target release | | --- | --- | | Add an **HTTP health probe** to check pod health. | 4.19 \(April 26, 2025\) | | **Thread analysis** Profile CPU component to identify any issues with memory management. | Completed. None found. |

Dec 6, 2024 · resolved Dec 6

Attempting to launch sessions in the public cloud and some customers private clouds resulted in a DH-500 error message and the session would fail to launch.