a month ago
We run two services (api and worker) from one repo in a single project environment, both with GitHub autodeploys and watchPatterns over the same paths.
Railway creates one GitHub Deployment per (commit, project + environment). The payload is always exactly:
{"environmentId": "12345"}
Both services then post statuses into that one record, with an empty description and a project-level log_url, so there's no way to tell which service each in_progress / success belongs to.
Three questions:
- Is
serviceIdever present ingithub.event.deployment.payload? Several third-party write-ups say to filter withgithub.event.deployment.payload.serviceId, but it's absent from every one of our deployment records and from your GitHub Actions Post-Deploy guide, which filters ongithub.event.deployment.environment. - If not, is there a supported way to distinguish services in a
deployment_statushandler when several share an environment? - Is
in_progress→inactivewith nosuccessthe intended signal for "watchPatterns did not match, nothing deployed"? We see exactly that on commits touching no watched path, and want to confirm we can rely on it.
Context: we're deleting a custom release verifier in favour of reading your GitHub Deployment records, so we want to be sure we're reading them the way you intend.
Thanks,
Vlad
3 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Yes
myself4444
Yes
a month ago
Could you confirm which of the three you're answering, and ideally point at where serviceId appears?
I checked every GitHub Deployment this repo has ever received: 85 records created by railway-app[bot], and the payload on all 85 is exactly {"environmentId": "..."} with no other key. serviceId has never appeared in any of them, and nothing else in the deployment or its statuses names a service. description is "Deployed to Railway" and environment_url / log_url / target_url are all project-scoped.
So github.event.deployment.payload.serviceId evaluates to empty here. Is that expected for a project with two services in one environment, or does it suggest we're on an older integration version?
a month ago
Worth double-checking the current version of the GitHub Actions Post-Deploy guide — as of now it does show github.event.deployment.payload.serviceId as the documented way to filter multi-service deployments (if: github.event.deployment.environment == 'production' && github.event.deployment.payload.serviceId == ''). So per Railway's own docs, serviceId is supposed to be in the payload.
That makes your finding — 85/85 real deployment records containing only {"environmentId": "..."} with serviceId never present — a genuine discrepancy between documented and actual behavior, not something where you're missing a step. That's worth stating explicitly to Railway: either the docs are stale, or there's a regression/version gap in what your project's integration is actually sending.
I can't confirm your third question (whether in_progress → inactive with no success is the intended "watchPatterns didn't match" signal) from docs — that's an internal behavior contract, not something documented publicly that I could find. That one genuinely needs a direct answer from Railway rather than inference.