2 months ago
Our production service "IMATA-Logistics" deploys successfully (deployment shows SUCCESS), but the application keeps crashing or restarting at runtime. We need help determining whether this is platform-related (resources, networking, build/runtime) or something we must fix in the app.
STACK
- Next.js app on Railway (production)
- Node.js runtime, Prisma/PostgreSQL, scheduled jobs/cron as configured
REPRO STEPS
1. [e.g. Open https://…]
2. [e.g. Hit /api/… or wait for cron]
3. Crash occurs when: testing out the deployment in the website
WHAT WE’VE CHECKED
- [ ] Recent code or env changes before crashes started
- [ ] DATABASE_URL / migrations / Prisma client generate
- [ ] Memory usage (possible OOM) in Metrics
- [ ] Same build works locally
QUESTION FOR RAILWAY
Can you confirm from your side whether the process is exiting due to OOM, platform limits, health check failures, or another infrastructure signal? Any guidance on recommended plan limits or settings for a Next.js + Prisma workload would help.
Repo / template: [optional: private repo name or “private — can grant access if needed”]
Service: desirable-eagerness / IMATA-Logistics / production
1 Replies
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
2 months ago
Hello Francis! Based on the your description, this sounds more like a runtime/app issue than a Railway build issue.
A Railway deploy can become active once the container starts, and healthchecks are only used during deployment, not as ongoing monitoring. I’d verify four things first:
(1) Next.js is built in standalone mode with the correct start command,
(2) the app is binding to 0.0.0.0 on Railway’s PORT,
(3) deploy logs + Metrics around the exact restart time to check for runtime exceptions or exit code 137/OOM, and
(4) whether scheduled jobs are running inside the same web service. If they share the same process, separating web and cron is usually the cleaner production setup. Railway’s docs point to host/port mismatch, runtime errors, heavy load/resource pressure, and startup/healthcheck timing as the main places to look first.
Please let me know if helped.