The live coverage and archiver health sections of railway postgres pitr status work by opening an SSH session to the running Postgres container. If that probe can't connect, those sections show as unavailable and the rest of the command still returns normally. A no_ssh_key result there doesn't change your PITR configuration or your database.

The documented options for pitr status are the target selectors (--service, --environment, --project) and --json. Unlike railway ssh, it has no --identity-file option. We have not verified how it chooses among keys loaded in your agent. We also have not verified whether maxRestoreTime or archiver health can be read without the SSH probe, so we aren't pointing you to an alternative dashboard or API method for those values.

Thank you for the explanation. However, this does not resolve our issue.

Our registered SSH key has the correct fingerprint and is successfully loaded into the SSH agent. The same identity previously worked with railway postgres pitr status, but the live coverage and archiver checks now consistently return no_ssh_key.

We understand that this does not affect the PostgreSQL database or PITR configuration. Our production recovery qualification is blocked because we cannot obtain fresh, certified maxRestoreTime and archiver-health evidence.

Could a Railway engineer please investigate and advise:

1. How does railway postgres pitr status select the SSH identity from the agent, and why might it report no_ssh_key despite the registered key being loaded?
2. Is there a supported workaround to explicitly provide the existing SSH identity?
3. Is there an official way to retrieve the certified maxRestoreTime and live archiver health without this SSH probe?

We have already verified that authenticated Dashboard Console SQL access works.

We need a supported resolution before proceeding with a production PITR restore qualification.

Could this thread please be escalated to a human engineer?

Thank you.

For the restore window, the Backups tab on your Postgres service gives you a way that doesn't use SSH. Its point-in-time recovery section shows the available restore range and the restore picker. You can read the current window there, alongside the read-only access you already have through the Dashboard Console. The only way to check archiver health that we can point you to is the live section of railway postgres pitr status, and that section depends on the SSH probe.

pitr status takes the target selectors (--service, --environment, --project) and --json. It has no identity-file option like railway ssh --identity-file. So we can't give you a supported way to point it at a specific key from your agent. We also haven't confirmed how it picks a key or what makes it return no_ssh_key even though your registered key is loaded. We won't guess at a workaround, since that could weaken your host-key checking or mean replacing keys.

A no_ssh_key result only means that section couldn't be shown. Your PITR configuration and database are unchanged, and checking status doesn't write anything.