Looks like you got hit by two separate problems: external traffic + an in-app leak.

• Network graph: those perfectly regular ~1 MB red spikes (Jun 7–10) are almost always a bot or cron job polling the same route on a timer. When you changed the URL, the traffic vanished—so it’s definitely external.

• Memory graph: the heap keeps climbing to >1 GB and stays there even after the traffic stops. That’s a classic leak (objects still referenced after the requests finish), not just GC pressure.

How to track it down quickly

# 1) Reproduce in staging
autocannon http://localhost:3000/problem-route -d 30 -c 20

# 2) Grab two heap snapshots
node --inspect=0.0.0.0:9229 server.js
# Chrome → chrome://inspect → Memory → Heap Snapshot
#   A) right after boot
#   B) when RAM ~1 GB
#   Diff on “Retained size”

The diff will highlight the constructor (e.g. Buffer, Array, or your own class) that’s ballooning.

Quick band-aids while you debug

app.use(express.json({ limit: '1mb' }));     // cap POST bodies
// If you stream files, pipe them instead of res.send()

• Add a simple rate-limit to that route (express-rate-limit).

• Restart on >800 MB with PM2: pm2 start server.js --max-memory-restart 800M.

Once you cut the reference that keeps those objects alive the baseline should drop back to ~250 MB.

Hope that helps—ping back with the heap-diff if you’d like another pair of eyes!

Since changing the url helped, makes me think this was unwanted network traffic.
You should investigate for memory leak. @abuhmhai has given some steps for it above.

If it is network related try putting your services behind Cloudflare.

This link can help https://docs.railway.com/tutorials/proximity-steering#3-creating-the-load-balancer