We need to apply two non-secret feature-flag changes to an existing Hobby service without duplicate deployments or data loss. The saved settings show zero for both flags, but the service Console process still reports one as one and the other as unset. We have paused testing until configuration propagation is verified.

Observed sequence (UTC):

• 2026-10-28 02:05: reviewed two intended variable changes and clicked Deploy once. The pending-changes banner disappeared and variable-change events appeared in Activity.
• On 2026-10-29, the dashboard still showed an Active deployment from seven days earlier and no newer deployment visible. The service remained Online and there was no pending-changes banner.
• The operator checked only those two saved settings individually and confirmed zero/zero, without modifying or saving them again. Separate Console-process comparisons indicated one/unset. We have not established that this Console environment matches the web application's process.

We have not repeated Deploy, restarted, changed credentials, uploaded new source, or modified application data during this investigation. We have not shared environment dumps, logs, identifiers, or customer data. The service was previously deployed via CLI.

Could you explain how to check, using non-secret deployment metadata, whether the original request was created, skipped, committed without deployment, or failed? What is the safe way to apply only the intended configuration once without duplicating an existing request?

We also saw a Railway staff reply saying some earlier source snapshots cannot be reused after the October 21 incident: https://station.railway.com/questions/can-t-deploy-and-logs-don-t-show-anythin-6c48dce8 . Could that affect a variable-only deployment for a CLI-deployed service? We have not confirmed that it applies here.

An AI assistant suggested contacting support because the available read-only dashboard checks did not explain the missing deployment, and its existing CLI path was unavailable. These tool limits do not establish that only Railway can resolve the issue. We are requesting diagnosis, not authorization to restart, redeploy, or change resources. Resource identifiers are omitted from this public draft; please indicate an appropriate private route if they are needed.

Prepared with Railway's support template (v1).