5 days ago
We are validating deployment-retirement evidence from the public GraphQL API. Could you confirm whether Deployment.statusUpdatedAt always records the transition into the currently returned Deployment.status?
For status REMOVED with deploymentStopped:true, does that timestamp mark the removal request, entry into REMOVING, entry into REMOVED, or completion of stopping all instances? If it does not provide a supported terminal-event timestamp, which public API field or event does?
The public CLI schema exposes statusUpdatedAt as a nullable DateTime without a description: https://github.com/railwayapp/cli/blob/master/src/gql/schema.json . The deployment lifecycle documentation describes removal but does not define this timestamp.
A brief field definition or documentation link is sufficient; no account access or configuration change is requested.
1 Replies
5 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 5 days ago
5 days ago
Hey — for retirement evidence from the public GraphQL API, here is what official docs (and the published CLI schema) actually define, versus what they leave open.
What docs do define
Deployment lifecycle: older Active/Completed/Crashed deploys are removed by first moving to Removing, then Removed; Remove also marks a running deploy REMOVED and moves it to history (Deployments reference). Teardown overlap/drain is controlled with RAILWAY_DEPLOYMENT_OVERLAP_SECONDS / RAILWAY_DEPLOYMENT_DRAINING_SECONDS (Deployment teardown).
Public API status table includes REMOVED (“Deployment was removed”) plus stop / cancel / remove mutations (Manage deployments).
statusUpdatedAt — undocumented
Docs do not define Deployment.statusUpdatedAt. The public CLI schema exposes it as a nullable DateTime with no description (CLI schema.json). So we cannot truthfully say it always marks entry into the currently returned status, or whether for REMOVED + deploymentStopped:true it is the remove request, entry into REMOVING, entry into REMOVED, or completion of stopping instances. Treating it as a guaranteed terminal-event timestamp would be inventing semantics.
Closest published / schema-described signals
statustransitions you observe (including Removing → Removed per reference) are the documented lifecycle signals.deploymentStopped: schema description is “Check if a deployment's instances have all stopped” (Boolean) — that is the field with an explicit stop/completion meaning in the published schema. Prefer that (plus status) over assumingstatusUpdatedAtmeaning.- For intentional removal actions, use the documented stop / cancel / remove API paths (Manage deployments); those change deployment state, but still do not document
statusUpdatedAt.
If you need a supported terminal timestamp for compliance, ask Railway staff to confirm or document statusUpdatedAt — the public surface does not define it today.