Hey there! We've found the following might help you get unblocked faster:

• 🧵 Postgres Database Container Took Too long to Start

If you find the answer from one of these, please let us know by solving the thread!

Hi, this suggestion doesn't seem to apply to my case.
While my service does use a Postgres database, the database is already deployed and running fine — there have been no startup delays or connection issues from the application's side.

The service in question is a long-running background cron job that logs every 5 seconds. It had been running successfully for over a month. There are no crash logs, no restart loops, and no memory spikes in the metrics. Logs were consistent and healthy right up until the service was removed.

The deployment was removed with the message:
"Deployment was removed because it's been crashed for too long"
…but I see no evidence of a crash in any logs or metrics.

This looks more like a false crash detection or automated cleanup on your end.

If there’s any issue on my side that caused this, please let me know — I’m happy to fix it.
Otherwise, I’d appreciate it if someone could investigate this further from your side.

Hi there, could you please provide your project and service ID?

project id - 6720c6fd-f8d2-4248-b8af-5a2050ac9380
service id - d3977a40-65e7-40d1-992f-6d270f6e80d5

Hello,

Your application has crashed because it used too much memory (> 8GB) on July 15th. You can see that this has happened twice by looking at the activity panel within your project canvas.

This would be an application-level issue, so we are unable to provide support here. We are only able to provide support for the Railway platform and product itself.

I will go ahead and open this up to the community in hopes that they can help you debug why your application attempted to use more than 8GB of memory.

Best,
Brody

Hi Brody,

Thanks for your response. I understand the concern regarding the memory spike on July 15, but I want to clarify that this doesn’t seem to explain the removal that happened on July 31 at 2:37 AM, which is the real issue I'm reporting.

From July 15 onward, the service continued to run without any crashes, restarts, or memory issues, and was logging every 5 seconds without interruption. There are no crash logs on or around July 31, and the last log entry happened exactly when the deployment was removed — not before.

Additionally, even after the removal, the metrics panel shows:

• Constant 2GB+ RAM usage

• 0.7 vCPU usage (which is unusually high for this service)

• Continuous network egress

This suggests that the container might still be running in a zombie or orphaned state, even though the deployment was removed from the dashboard.

If there is still a memory issue on July 31 that caused the removal, could you please help me pinpoint that in the activity panel or logs? I'm happy to investigate and fix it, but I need confirmation that it actually occurred on July 31 — not just two weeks earlier.

Thanks again for your time, and I’d appreciate further help or escalation if possible.