Hi team,

We're seeing persistent failures on the variableUpsert GraphQL mutation

across our entire project — affects newly created services AND existing

services. Started 2026-06-02 and still ongoing on 2026-06-03.

Account / Project:

• Project ID: e3068361-49f0-4544-8bec-a83db3854e30
• Environment: production
• Environment ID: c9eb5bdf-839b-4575-98af-4591ca360afd

Symptom:

• variableUpsert(input: { projectId, environmentId, serviceId?, name, value, skipDeploys: true })

  returns HTTP 504 (Cloudflare gateway timeout, HTML body) on most calls.

• After multiple retries, some eventually land (the mutation succeeded

  server-side even though HTTP returned 504). Others continue to fail or

  return GraphQL error: { "message": "Problem processing request" }.

• Same failure mode on project-level shared variable writes (no serviceId)

  AND on per-service writes (with serviceId).

• Same failure mode on existing services AND on newly created services.

• variableDelete calls in the same project work fine, no 504s. Only

  variableUpsert and sharedVariableConfigure exhibit the timeout.

Reproduction:

1. POST graphql/v2 with variableUpsert mutation

2. Connection times out at ~60s with HTTP 504

3. Retry → same result, until eventually it lands or hits the GraphQL

   "Problem processing request" error

Sample traceIds from "Problem processing request" responses:

• 6137817602381378991
• 8287597822565014605

Status page reports "fully operational" but the history shows

"Elevated Deploy Times in US East" incidents on June 1-2.

We have automated deploys that depend on this mutation. A significant

fraction of deploys end up in a half-built state because the variable

writes never succeed.

Questions:

1. Is the variableUpsert pipeline degraded for our project? What's queued

   on your end?

2. Is variableCollectionUpsert a more reliable alternative?

3. Can you investigate the traceIds above?