Confirmed that only some services are being affected.
Example of another Bun API that wakes up fine -- Service ID: da0153da-2b2d-4ea2-aed8-e6791380c74a

That API is using a similar stack as the ever-sleeping one and they are in the same project.

please go ahead and redeploy

is it a known issue?

ive seen it before, yes

this pretty much breaks App Sleep for me, I can't be awake myself all the time to redeploy my apps when that happens lol

i have to ask, why even use app sleep with its current issues?

to save resources? isn't that the reason it exists?

well yes, but does the app in question use a lot of resources to begin with?

no, but I have several of them, and the usage adds up

honestly speaking, better than not wakeing up imo

I'd rather have the feature working as intended 😛

of course but for right now, unless your service uses a lot of memory, i dont think app sleep should be used

in the mean time, ive added your deployment to our internal ticket

I won't redeploy the app (I don't need it atm), so feel free to use it to test if needed

i dont know when we could allocate time to test this though

new error 👀 I have never seen a status 499 before

thats client closed the connection

I'm just refreshing the public URL

yeah that would be the client closing the connection

yesterday I faced the same issue, My spring boot app was not waking up, it was sleeping since two days

I checked the doc and they mentioned there that you have to sometimes rebuild/redeploy to wake up the app

I don't see anything of the sort in the docs: https://docs.railway.com/reference/app-sleeping

Slept services still consume a slot on our infrastructure, enabling App Sleeping de-prioritizes your workload and in remote cases, may require a rebuild to re-live the service.
It would be good to know what "remote cases" may be

The affected app was moved to Metal (without my knowledge). Not sure if it happened when I redeployed it, but it seems to be waking up correctly on request. I'll keep testing over the next few days.

I've tested this with multiple apps (both Metal and ones moved back to non-Metal) over the past few days and they're waking up correctly.

My guess is that this happened because the affected apps were moved to Metal while they were asleep. Then the first request (on Metal) failed to wake up the app because it fell asleep while on non-Metal. Or something like that. That would explain why a redeploy fixed it. If the time I opened this thread matches with the moving, then that could be it.

The 502-on-first-request thing is still happening, but that's a different issue. Either way, this one can be closed 👍

This problem seems to have returned.
I've got one app in eternal slumber and it won't wake up on requests (see second image for request log).
The non-metal (plastic 😛 ) service woke up fine.
Affected Service ID: ae4c8ca4-00b8-415b-ac10-4baa1612691f

Also just noticed App Sleep got renamed to Serverless.
Let me know if you guys want to debug the sleeping app instance before I restart it. (I'm not using it atm so I can leave it as-is for now)

can you provide the deployment id?

74c8d10d-1a2d-49a6-a957-5bcce93aa86d

thank you, i bumped the ticket with this information

go ahead and redeploy, i dont want to block you from using the service

👋 this has happened again.

• Service ae4c8ca4-00b8-415b-ac10-4baa1612691f

• Deployment f27567f7-7054-4d38-a753-7c0cc235f367 (does not wake up on request)

Exactly same behavior as before: some of my services moved to Metal yesterday (again?), probably because when it first happened I moved some back to non-Metal.

The affected eternal sleeping service was already running on Metal. It just happened when some OTHER project got moved to Metal in my entire account. This seems to always happens when my account's projects are upgraded to Metal.

Was there a move to Metal yesterday on my account? I'm seeing several deploys "started by Railway" with the reason "moved to Metal". I'm 100% sure this caused the issue but I thought this move was finished many months ago?

Either way, the deployment above is for an API I don't actively use. It's currently sleeping and won't wake up on request. I'll leave it asleep in case you guys want to debug.

EDIT: this seems to be actively going on (projects being moved to Metal), see image with a deploy "16 minutes ago" not initiated by me.

Everyone has already moved to Metal; you wouldn't be able to move back to Legacy, as we removed that ability.

This is just an outdated UI element that really pertains to this -

As for the service not being able to be woken up, our documentation does mention that as a caveat, so that would be the status quo. -

are those "remote cases" that fall outside of "sleeping for a long time" on the roadmap to be looked at? or should I just expect app sleeping to fail occasionally?

We have not seen many cases of that, so we would not be able to prioritize improvements to that in the near future.

ok. For now I set up an external cronjob to hit my sleeping app and if it fails to respond twice (due to failure to wake up) I'll get an email.

(just wish I didn't have to do that)

I agree it's not ideal, but in the interest of transparency, we would need to see quite a few reports from other users in order for us to prioritize looking into this.

is there a way to know via an API or Discord or something when a platform update takes place, one that redeploys services in such a way? That would be a better way for me to restart sleeping services if needed.

We don't provide an API for that at this time.