Can you tell me more about when this issue started and whether you are still seeing it? We've had some issues with Github over the last day and a half and I'm wondering if it might be related.

I am new to the platform and notice this for the past 2 or 3 days. And it's still the case now.

Another observation is that, of the 4 very similar services from the same git repo, only one shows this behavior. The rest are deploying properly

The behavior you're describing, where deployments are immediately removed with no logs, matches what happens when Watch Paths are configured and the changed files don't match the patterns. Even though you mentioned no Watch Paths are set, I'd suggest double-checking the specific service that's misbehaving since only one of your four services shows this issue. Go to that service's Settings tab and look under the Build section for Watch Paths. Compare that configuration with one of your working services from the same repo. Also compare the Root Directory setting between them, as differences there could explain why changes trigger successful deployments on some services but not others. When you change any other setting, it forces a deployment regardless of watch path filtering, which explains why that workaround succeeds.

I gave a try, nothing came up, all configs looks the same except that the problematic one is a normal service, the others are configured as cron job. And when I toggle between no Watch Paths, and /backend/**, same behavior, no build actually triggered --- btw, I use the toggle to manually trigger the builds. Any other advices?

The deployment history shows a pattern where multiple deployments are being triggered within seconds of each other, causing a supersede cascade - Railway keeps only the latest deployment and removes in-progress ones. At 19:35 UTC on Jan 31, four deployments were triggered within 3 seconds, and three were immediately removed. This explains the "REMOVED" status with no logs: the deployment never built because a newer one replaced it before it started. The key difference is your cron job services don't auto-deploy on every git push the same way a normal service does, which is why they don't exhibit this behavior.