a month ago
Subject: [Needs human engineer] Cron job schedule metadata stuck on stale value — already triaged by Railway AI agent, needs backend resync
Note: I already went through triage with the Railway AI agent, which confirmed this diagnosis (config layer correct, metadata layer stale) but explicitly said it does not have access to force a backend metadata resync — that requires a human engineer with direct access to the metadata sync layer. Escalating here rather than re-running the same diagnostic conversation.
Project: robust-solace (5618c3a0-076d-4a0c-9fa8-35221f36c3ac)
Service: flow-structure-bot (26db3ad7-29dc-40ef-afa8-42984b835e5c)
Environment: production (10c03f4c-0634-4827-b59f-906d7668fc02)
Current deployment ID: 5255625d-464b-430a-8340-f16e69f3888c
Summary
The cron execution engine is working correctly and follows railway.toml on every deploy. However, a separate metadata layer (used by railway status CLI and the dashboard cron widget) is stuck on a stale schedule from a subscription event ~2026-07-08/09, and is not syncing when cronSchedule config changes are pushed.
Evidence
Actual executions are correct (verified via deploy logs, timestamps below):
- Deploy 1 (2026-07-11 ~22:30 UTC): pushed cronSchedule = "*/6 * * * *" (commit cc7f270). Deploy logs confirm invocations at 22:30 and 22:36 UTC — exactly 6 minutes apart ✓.
railway statusstill showed: */5 13,14,15,16 * * 1-5 · next run in 2 days ✗ - Deploy 2 (2026-07-11 22:38:45 UTC): reverted to cronSchedule = "*/5 * * * *" (commit 70041be). Deploy logs confirm invocations at 22:40 and 22:45 UTC — exactly 5 minutes apart ✓.
railway statusstill showed the same stale schedule ✗ - Deploy 3 (2026-07-11): empty-commit redeploy specifically to force cron metadata resync (commit d86632f). No effect on metadata.
As of this ticket, railway status still shows:
*/5 13,14,15,16 * * 1-5 · next run in 2 daysImpact
Live trading bot; schedule is mission-critical. Every push to change cronSchedule executes correctly, but metadata doesn't update. This breaks observability — we cannot trust railway status or the dashboard's cron widget to reflect the actual running schedule, which is a real risk for monitoring a live production trading system.
What we've tried
Three separate real config changes with full rebuilds, plus one empty-commit redeploy — no effect on the metadata. Actual cron execution has followed the correct schedule every time, confirmed via deploy logs.
Request
Could a human engineer force a metadata resync on the server side for this service? The execution engine is clearly reading from the right place; the metadata layer just needs to be invalidated and refreshed from the service's current config. We'd prefer not to delete/recreate the service since it's a live bot, but are open to whatever's needed.
1 Replies
a month ago
This is the documented behavior of config as code, not a metadata sync issue. Per the docs: "The settings in the dashboard will not be updated with the settings defined in code. Configuration defined in code will always override values from the dashboard." Your railway.toml correctly drives execution on every deploy (your logs confirm this), but the dashboard and railway status CLI display whatever was last set through the dashboard UI, which is the old */5 13,14,15,16 * * 1-5 value. To fix the display, update the cron schedule field directly in your service's Settings page to match your current railway.toml value.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved underzero41 • about 1 month ago