Platform service status
Availability and latency for the four business lines and the tool matrix, refreshed every 30 seconds. This page shows aggregated platform telemetry; for customer-specific deployments, availability is governed by each environment’s own monitoring.
Current status by service
cn-shanghaicn-shanghaicn-shanghaicn-shanghaiglobalglobalAvailability targets
These targets are not slogans — they drive on-call rotations and alert thresholds.
Measured monthly, excluding planned maintenance windows
On call 7×24; P1 within 2 hours
Local JWKS verification, no origin lookup
Changes within the window are rollback-able
Incident history
Everything that has happened or is being handled is recorded here, including response steps and root cause.
All monitored services are operational. Historical incidents are archived in resolution order with root-cause analysis and follow-up items; records are never deleted.
The remote MCP access path is seeing intermittent timeouts; the local CLI and desktop app are unaffected. We are investigating the upstream network path and have switched to a backup endpoint. Integrated callers should configure client-side retries.
This page reflects aggregated platform-side telemetry and how we approach availability monitoring and incident disclosure. Customers with private deployments run their own monitoring; availability is measured by each environment. Alert-channel integration and SLA reconciliation can be configured together during delivery.
Hand the complexity of identity, agents and private domain to one governable kernel
Whether you are replacing an existing IAM, building an agent platform, or trying to make private-domain operations actually work — start with a 30-minute architecture call. We will first judge whether this is the kind of problem we are good at, and say so plainly if it is not.