1. Verify Tracked Branch

Run this CLI command to bypass the dashboard error and pull the configuration directly from Railway's engine without triggering a deployment:

railway api 'query($id: String!) { service(id: $id) { source { repo branch } } }' --var id="YOUR_SERVICE_ID"

1. Inspect Staged Patch (No Secrets/Values)

Execute this GraphQL query to audit the field names and structural deployment changes without exposing decrypted variable values:

query checkPatch($environmentId: String!) {

environmentStagedChanges(environmentId: $environmentId) {

components {

  serviceId

  variables { key isDeleted }

  serviceInstance {

    startCommand buildCommand rootDirectory

    deploy { numReplicas restartPolicyType }

  }

}

}

}

Yes you can check both read only with the Railway CLI.

Update the CLI (railway upgrade) and log in. Then use railway api search source and railway api describe ServiceInstance to find which field holds the repo and branch. Your dashboard error doesn't affect this, because the CLI queries the API directly.

For the branch run a query on the field you found, for example railway api 'query($id: String!) { ... }' --var id=YOUR_SERVICE_ID. Check the field names with describe first because the exact path may differ from examples.

For the staged patch, the API returns it as one JSON object with no sub-fields, so you can't request only the field names. Pipe the output into jq so only the key names print for example railway api '...' | jq '[paths | map(tostring) | join(".")]'. The variable values stay in the pipe and never appear on screen.

Only run queries not mutations so nothing changes.

I checked the current public GraphQL schema using unauthenticated introspection (schema only, no project data). There is a limitation here under your requirement not to retrieve variable values.

The branch examples above do not match that schema: Service has no source field, and ServiceInstance.source returns ServiceSource, which exposes repo and image, not branch. DeploymentTrigger does expose branch, but empty trigger results do not establish that a service has no configured branch. Service.repoTriggers also returns DeploymentTrigger nodes, so it is not a separate service configuration source.

Railway's published EnvironmentConfig JSON schema places the configured branch under services[serviceId].source.branch. EnvironmentConfig is a GraphQL scalar, so GraphQL cannot select only that nested branch. I could not find a current branch-only configuration field independent of triggers or that scalar. Given your empty triggers/no deployments, I would not infer a branch name or use a deployment commit as evidence of the configured tracking branch.

For the staged patch, this query is valid against the schema and requests metadata only:

query PatchMetadata($environmentId: String!) {

environmentStagedChanges(environmentId: $environmentId) {

id

status

createdAt

updatedAt

}

}

It intentionally does NOT identify the changed fields. EnvironmentPatch has no components field. Its patch(decryptVariables: Boolean) field returns the EnvironmentConfig scalar. Setting decryptVariables: false is not a keys-only projection, and piping the response through jq still retrieves the payload before filtering it. That would not satisfy your constraint, even if no values appear in the terminal.

So the metadata query can inspect the patch record without requesting config, but I cannot substantiate a public API query that answers both of your exact questions without retrieving the config/patch payload. A server-side branch-only or changed-paths projection from Railway would be needed to meet that boundary. Nothing here requires applying/discarding the patch, enabling autodeploy, or triggering a deployment.

Sources for reproducing the schema check:

https://railway.com/graphiql

https://backboard.railway.com/schema/environment.schema.json

https://docs.railway.com/cli/api

AI-assisted answer; schema-verified, not executed against your project.