Hello Railway team,

We are preparing a dedicated hourly Cron service for a short-lived Django

cleanup management command, separate from our Web service, on a Hobby

account. It would use a Dockerfile image, one replica, private database

networking, no public endpoint or volume, an explicit cleanup start command,

and an explicitly empty pre-deploy command. Source changes/autodeploys and

manual Run Now actions would be disabled during the validation.

We have read the Cron Jobs, Restart Policy and Variables documentation.

We understand that schedules use UTC, execution times can vary, and the

published Cron documentation says jobs must terminate themselves.

Before provisioning, could you clarify the following supported behavior?

1. Start triggers and run identity

If the Cron schedule is configured before the first deployment, can the

initial deployment, schedule activation, or a later source/configuration

change start the command immediately outside the schedule? What supported

run/deployment identifier and start/end/exit metadata distinguish actual

executions from duplicated log lines?

1. Automatic retries

Does restartPolicyType=NEVER apply to Cron executions? If not, what is the

actual retry behavior after failure, and is there a supported way to disable

automatic retries? Please distinguish retries from a later scheduled run.

Our proposed validation budget is two scheduled runs, not a claim that cron

provides exactly-once execution in all circumstances.

1. Overlap

The docs describe skipping a tick while a prior run is still active. In the

Central Station thread "Cron job - run overlaps but next is not skipped"

(identifier 757fa4fd), an EMPLOYEE reply acknowledged contrary behavior at

the time. Has that issue been resolved for the current Cron implementation?

If provider-side exclusion is not supported, please say whether the job

must implement its own concurrency protection.

1. Deadline

The Cron docs say Railway does not automatically terminate a stuck job.

Is there now a supported per-execution hard deadline? If not, please confirm

that bounded termination must be implemented by the application/entrypoint,

rather than assuming Web healthcheck or draining time is a Cron deadline.

1. Disable and stop

What exact supported action prevents future and already queued executions

without converting the Cron service into an always-running service? What

separate action stops an in-flight run? If deletion of the dedicated service

is the supported method, what happens to queued/running executions and what

metadata confirms completion? We will not assume clearing cronSchedule is

an atomic pause operation.

1. Domain-variable behavior without a public endpoint

Our shared staging validation checks the Web public-domain value even for

management commands. Can a Cron service with no generated/custom domain

explicitly set RAILWAY_PUBLIC_DOMAIN=${{web.RAILWAY_PUBLIC_DOMAIN}}? Does the

reference take precedence over the platform-provided variable in this case?

If that variable cannot be overridden, please identify the supported

alternative. We do not want to expose an HTTP endpoint solely for a cleanup

job or bypass our staging validation.

Explicit statements of what is not supported are useful. We are asking

about platform behavior, not permission to bypass application safeguards.

Please do not create, restart, deploy or modify any service while answering.

Thank you.