I would treat this as a broken Railway variable reference first, not an app-level secret rotation problem.

The wording secret Service not found usually points to Railway trying to resolve a reference variable that points at a service that no longer exists in that environment. For example, a variable like:

DATABASE_URL=${{ Postgres.DATABASE_URL }}

API_URL=https://${{ backend.RAILWAY_PUBLIC_DOMAIN }}

will break if Postgres or backend was renamed, deleted, recreated, moved, or is not present in the environment used by that deployment.

What I would check:

1. Open the failing service, then open its Variables tab.
2. Switch to the same environment where those failed deployment IDs came from.
3. Look for any value that contains ${{ ... }}.
4. For each ${{ SERVICE_NAME.VAR }} reference, confirm that SERVICE_NAME is still an existing service in that same environment.
5. If the referenced service was renamed or recreated, delete the stale reference and recreate it with Railway's variable autocomplete so it points at the current service.
6. Review and deploy the staged variable changes.

Do the same check for shared variables if any service is pulling values from Project Settings -> Shared Variables.

I would not rotate the actual secret values yet. If the service name inside the reference is stale, rotating the value will not fix it because Railway still cannot resolve the service part of the reference.

If every ${{ ... }} reference is valid and the error still happens on a fresh redeploy, then the two deployment IDs you listed are the useful identifiers for Railway to inspect. But the fastest self-check is the variable-reference scan above, especially if a service was recently deleted, duplicated, renamed, or moved between environments.