[Feature] Server notifies clients when it becomes available

[JannieP]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Clients can only discover that the server is up by asking it. There is no way for the server to announce it. On a server that is not always running, the client's polling schedule and the server's availability have to coincide by chance.

Running Immich on infrastructure that stops when idle and starts on demand is a common self-hosted setup, and it hits this consistently. With a server that sleeps:

• The Android periodic worker runs hourly (PeriodicWorkRequestBuilder(1, HOURS, 15, MINUTES)).
• Its first request wakes the server but meets a 503 while it is still starting, so _syncAssets fails and the run is abandoned before _handleBackup().
• An hour later the server is asleep again, and the next run meets the same 503.

Backup never completes, rather than completing late.

Proposal: a server-lifecycle event, fired when the server becomes ready, that clients or operators can act on. The flow becomes:

1. Client has work and sends a request, which wakes the server. It does not wait for a useful reply.
2. Server finishes starting and announces it.
3. Client does its pending work immediately.

No polling, no retry loop, no wakelock held across a boot, no hard-coded timeout guessing at cold-start duration (35-50s here). It also makes aggressive idle-stop timers safe, because the server can summon clients rather than needing to stay up long enough to be found by one.

This does not remove the need for a client request to wake a sleeping server — nothing can, since a stopped server cannot announce anything. It closes the loop on that request.

Possible shape: the workflow system already has an httpRequest action, so the outbound half exists. What is missing is a trigger that is not asset-scoped — every WorkflowTrigger today maps to WorkflowType.AssetV1 and the execution path assumes a user and an asset, so a ServerReady trigger would need a server-scoped workflow type. Operators could then wire it to whatever they use, and Immich would not need to take on push infrastructure itself.

The detail that decides whether this works: the event must fire when the server is serving, not when the process starts, or the race simply moves one layer up.

Platform

• Server
• Web
• Mobile

[github-actions[bot]]

This discussion has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

[JannieP]

This is not a duplicate. I searched open and closed issues and discussions before posting; the nearest match is #26018 (server hangs after docker unpause), which is a different problem — that is the server failing to recover, this is about the server having no way to tell clients it has recovered.

The body has also been rewritten to follow the feature request template, which it did not when the bot first saw it — that is likely what tripped the check.