Uptime checksHTTP, keyword and TLS checks on your addresses, with the evidence of every failure kept.
Cron heartbeatsOne curl line at the end of a job. Silence past the grace window is the alert.
Status pagesA page your customers read, on your own domain, with the incident in plain words.
ExplanationsA written reason with the alert: what failed, what the checks saw, what to look at first.
on every plan Alerts to six channelsImportTeams
APIRead, pause, acknowledge and post updates from your own scripts.
MCP serverAsk your AI assistant what is down, then acknowledge or post an update.
WebhooksSigned JSON when an incident opens, is acknowledged or recovers.
Heartbeat guidescrontab, GitHub Actions, Railway, Node, Go, WordPress and Kubernetes.
DocsShort guides, each one task, with the lines to copy.
GuidesWhy monitors send false alarms, why cron jobs stop, and the fix.
ChangelogThe big things we shipped, newest first.
Trust and securityWhere your data lives, who processes it, how long we keep it.
Referral program soonRecommend Upglory to another team. In the works.
Contact
Docs menu Heartbeats / Railway

Monitor a Railway cron service.

One curl at the end of the start command. Three minutes, start to finish.

3 minute read Guide

Before you start

You need a heartbeat in Upglory with its period and grace set to match the service's cron schedule. Its page shows the ping address; put it in a service variable called UPGLORY_PING_URL, so the command stays readable and the URL is not in your repository.

Settings that match this schedule

  • Period1 hourThe cron expression on the service, not how long the command takes.
  • Grace15 minutesA container has to start before your command does. Leave room for the cold start.
  • Channelsemail, TelegramInherited from the workspace default. Change it on this heartbeat if it matters less than the others.

The line

A cron service runs your start command on the schedule and exits. Put the ping at the end of that command, joined with &&, so a non-zero exit sends nothing.

start command
node ./jobs/sync-stock.js && curl -fsS -m 10 --retry 3 "$UPGLORY_PING_URL"

Railway starts a cron service at the scheduled minute and will not start a second one while the first is still running, so a job that overruns its schedule shows up as a miss rather than two runs.

Measure the run time

Ping /start before the job. The ping at the end then records how long it ran, which is how you see a run creeping towards the next one.

curl -fsS -m 10 "$UPGLORY_PING_URL/start"; node ./jobs/sync-stock.js && curl -fsS -m 10 --retry 3 "$UPGLORY_PING_URL"

Report a failure

When the job exits non-zero, say so at once instead of waiting for the grace window to run out.

node ./jobs/sync-stock.js && curl -fsS -m 10 "$UPGLORY_PING_URL" || curl -fsS -m 10 "$UPGLORY_PING_URL/fail"

Test it

Use Send a test ping on the heartbeat's page, or run the curl by hand with the service's variable. Nothing alerts until the first ping arrives, so a job you have not deployed yet never raises an alarm.

What you will see if it stops

Fifteen minutes past the hour, the heartbeat turns down and the alert names the last ping. If the previous run is still going, Railway skipped this one: the run time is what to look at, not the schedule.

missed sync-stock
LATE due 14:00, grace ran out 14:15
last ping 13:01, ran 58 s
Email and Telegram told at 14:15

The other guides

Start free 20 heartbeats on Free, with no card