4 days ago
Hi Railway team,
Two GitHub-source deployments of campwatch-web in campwatch-prod / production failed at BUILD_IMAGE on 21 October 2026:
- 6fc0671f-a49f-4f08-be9f-bb648b06c85d — created 03:51:18 UTC, failed 03:55:36 UTC.
- a323ef9c-310a-4c62-a724-c7b8226e8bf9 — created 04:00:20 UTC, failed 04:04:37 UTC.
Both attempted main revision b0ea6fdac1fd383feb35c2f16be2215adbef0f5d. Each failed after about 4 minutes 17 seconds. The only available build log is “🚂 All aboard, next stop: builder v4”. The reported error is “Failed to build an image. Please check the build logs for more details.”
No Node/Railpack detection, parsed railway.json metadata, application build output, runtime logs, or image digest were recorded for either attempt. The deployment diagnosis is empty.
The previous deployment c5da9a51-06c7-4c82-8318-95a980ac168f, revision 0ea3cddc6c28a4a620c24fe3add6ac8b95cd5d40, remains healthy at https://www.campwatch.com.au. Between these source revisions, only documentation and integration-registry metadata changed; application code, dependencies, build configuration, and migrations are unchanged.
Could you inspect the internal source/snapshot and builder traces for these two failed deployment IDs, identify the cause, and advise one concrete recovery action? Please share your findings before making project configuration changes or triggering deployments, so we can preserve the healthy existing release.
Thanks,
Campbell
1 Replies
Status changed to Awaiting Railway Response Railway • 4 days ago
an hour ago
We checked both deployments. In each one, the step that fetches and packages your source from GitHub ran for nearly the full four minutes and then failed, so the build stopped before Railpack started. That is why your logs show only the builder banner, with no detection or build output. None of your application code, dependencies or build configuration was evaluated, and we found no recorded error that points to a cause in revision b0ea6fd.
We have not changed anything in the project or started any deployments. Your healthy deployment from 0ea3cdd is still the active release, and a failed build does not replace it.
The one recovery step we suggest is to trigger a fresh deployment of the same commit once you are ready, from the service or with a new push to main. If it fails again at the same point after about four minutes, that would show the failure repeats for this source revision rather than being a one-off.
Status changed to Awaiting User Response angelo-railway • about 1 hour ago