Intermittent failures and slowness in Japan region when opening the Apps runtime

Update timeline

1. investigating Jul 06, 2026, 01:53 AM UTC

   We are investigating an issue affecting the Apps runtime in the Japan region. Impacted customers may see delayed load times or failures when attempting to open deployed Apps. We will provide updates as more information becomes available.

2. resolved Jul 06, 2026, 02:40 AM UTC

   The issue is has been resolved and we are actively monitoring the application.

3. postmortem Jul 30, 2026, 10:32 AM UTC

   ## Customer impact Between July 5, 2026 at ~22:30 UTC and July 6, 2026 at ~02:00 UTC, a limited number of tenants in the Japan region experienced increased latency and degraded performance when using Business Apps. Some requests may have timed out during this period. ## Root cause During a routine service update, a database index used by a frequently-executed query was adjusted. The change itself was correct; however, at deployment the database generated a new execution plan for that query. The plan was built from a non-representative dataset \(a tenant with a small amount of data\), so it was not well-suited to production-scale data. As a result, for tenants with a large amount of data the query began executing inefficiently, which caused the increased latency and request timeouts that customers experienced. ## Detection The issue was detected through an automated latency alert at 00:44 UTC on July 6, 2026. ## Response The affected Orchestrator database was identified as needing additional capacity. Additional capacity was added to the database, after which the query regenerated an efficient execution plan and performance returned to normal. The incident was mitigated by approximately 02:00 UTC on July 6, 2026, and monitoring continued afterward to confirm recovery. ## Follow up * Activating query changes independently of deployment, so execution plans are generated against representative production data. * Tooling to detect and clear inefficient execution plans automatically, so the database can regenerate a better one. * Monitoring to flag when a single query consumes a disproportionate share of database resources, so we can act before performance is affected.