Uptime & alerts
Hear about problems before your users do: uptime checks that visit your app like a visitor would, and alerts to Slack, Discord, or any webhook.
Traffic
Every web service’s page has a Traffic panel showing what Cloudflare’s edge saw for its addresses and custom domains, per environment, over the last 24 hours, 7 days, or 30 days:
- Requests over time, visits, bandwidth, the share of server errors (5xx), how much was served from Cloudflare’s cache, and your app’s average response time.
- Top countries, pages, devices, browsers, and operating systems.
apprail traffic shop/web
apprail traffic shop/web --range 7d --jsonApprail collects it from Cloudflare every few minutes and keeps it for 90 days, so figures appear a few minutes after the requests. Counts are Cloudflare’s estimates — close to exact at everyday volumes. Location is by country only, and no visitor IP addresses are stored. Workers have no public address, so they have no traffic panel.
Alert channels
Channels belong to the workspace; owners and admins manage them, and every member can see where alerts go. Every channel receives every alert.
pbpaste | apprail alerts add ops --kind slack # the webhook URL, from standard input
apprail alerts add oncall --kind webhook --url https://hooks.example.com/apprail
apprail alerts test ops
apprail alerts- Kinds:
slack(an incoming-webhook URL),discord(a channel webhook URL), orwebhook(any HTTPS endpoint, sent JSON). - Test before you rely on it.
alerts test— or Send test in the console — delivers at once and shows the receiver’s answer. - The URL is a secret. It’s stored encrypted and never shown again; only its host is. Without
--url, the CLI reads it from standard input. - Reliable delivery. If the receiver is down, delivery is retried for about an hour. The channel shows its last delivery or error.
- URLs must be
httpson port 443 and point at a public address. Discord messages never mention@everyoneor anyone else.
What sends an alert
| Alert | When |
|---|---|
| Service down | An uptime check fails a set number of times in a row |
| Service recovered | The first successful check after it was down |
| Deployment failed | A deployment fails outside previews. The alert says the previous release is still serving |
| Job failing | A job run fails after the previous run didn’t — one alert, not one per failing run |
| Approval needed | A deployment is waiting in a protected environment |
Uptime checks
An uptime check requests a web service’s public address from outside, through the edge, every minute (or up to once an hour). 2xx and 3xx answers count as up; redirects aren’t followed; no answer within 10 seconds is a failure.
apprail uptime shop/web on
apprail uptime shop/web on --path /healthz --interval 60 --threshold 3
apprail uptime shop/web
apprail uptime shop/web off| Option | Default | Range |
|---|---|---|
--path | The service’s health path | Any path |
--interval | 60 seconds | 60–3600 |
--threshold | 2 failures in a row | 1–10 |
--env | production | Any environment |
The console shows each check’s state and 24-hour uptime. A service with nothing deployed is unknown, never down.
Checks run from Apprail’s own region. An outage that takes the whole region down can’t alert you from there, so for anything critical, add an independent external monitor as well.
Not available yet: email or SMS, escalation policies, routing different alerts to different channels, and maintenance windows.