where is the screenshot ?

and what do your Railway deployment logs show from the time Twilio tried to connect? , also how is your websocket server configured? are you listening on process.env.PORT (or the PORT environment variable) and are you binding to 0.0.0.0 or localhost? the answer to this questions will help me to help yoy

for the 2 issue slack webhook ;, are you calling it from browser JavaScript/client-side code (like testing in a web app)??

My fault here is the screenshot attached.

Regarding the Slack Webhook, I am calling it from the Railway UI to test. I'll attach a screenshot of that also.

Railway UI Testing Slack webhook

Railway UI Testing Slack webhook

Sorry not sure why uploading wasn't working! Okay @domehane here is my logs for that time around when it failed

for issue 1 :

twilio error 31901, your logs show you're hitting 500 logs/sec rate limit, that's killing your container's performance. your WebSocket shows isConnected=false when Twilio tries to connect because the server's overwhelmed

so you should remove excessive console.logs (especially in loops/message handlers) and make sure you're binding to 0.0.0.0 not localhost : server.listen(process.env.PORT, '0.0.0.0') and finally add a /health endpoint that returns 200 so Railway knows when your WS is ready

for slack webhook, nothing's broken railway's "Test Webhook" button calls from your browser which triggers CORS errors Slack webhooks don't support browser calls, so railway sends actual webhooks server-side, not from the browser. just trigger a real event (deployment crash, alert) or test with curl and you'll see it works perfectly the test button failing is normal for slack webhooks

so fix your logging spam for Twilio and ignore the Slack test button ; let me knew the result

tell me if you need more help

We removed the excessive logging and added a custom domain. Do you think that will help at all?

Haven't seen the issue yet since removing the logging and a custom domain.

yeah, removing the logging was definitely the main fix that 500 logs/sec was basically DoSing your own container and making it unresponsive when Twilio tried to connect

custom domain won't directly fix the WebSocket issue, but it's good to have for consistency. the logging was the real culprit, and since you haven't seen the error again, sounds like it's solved

Awesome thank you so much! You're great! Appreciate the fast support and great community here!

i'm always happy to help