Website monitoring for developers, wired into CI.
Chain the real calls — log in, take the token, place the order, read it back — and assert every response. Give each cron job a heartbeat URL, create monitors from a deploy step, and get paged in Slack, Discord or PagerDuty.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sFour failures that never throw
Every one of them is true the moment the pipeline goes green. None of them is still true at 03:00, when the running system has drifted and nothing has thrown.
"If something broke, we'd see an exception."
Error trackers only see code that runs. A cron entry that never starts, a worker wedged mid-job, a certificate that quietly expires — none of them throw. The worst failures aren't stack traces; they're silence.
"The pipeline is green, so prod is fine."
CI proves the code was good at deploy time. Expired tokens, full disks, exhausted quotas and drifting config all happen between deploys — in the running system your test suite never sees again.
"We'd hear about it fast — we're online all day."
You're at a keyboard 40 of the week's 168 hours — nobody is looking for the other 128. And users rarely report a broken checkout; they retry once and leave.
"It worked in staging, so it works."
Staging never has production's traffic, data volume, third-party quotas or DNS. The failure modes that page you at 03:00 are precisely the ones staging can't reproduce.
"We have a /health endpoint — we're covered" is the biggest one. A one-minute health check tells you 1,440 times a day that a process answers (24 × 60). The number of those checks that prove checkout completes, the nightly backup ran or the queue is draining: zero.
"A process answers" and "the system works" are different claims — and only one of them is the one your users care about.
So what does 03:00 look like on the night a job dies — when something is actually listening?↓ minute by minute
The night invoice-worker stopped
A deploy at 22:40 rewrote the crontab and dropped one line. At 03:00 the invoice worker didn't start, raised nothing, and every dashboard stayed green — the queue never moved.
That covers the job that died. But cron is only one of the surfaces that fail without a sound — every belief above has its own.↓ a monitor for each
Chains, pings and agents
API chains for services, inbound pings for jobs, real-browser flows for checkouts, a one-line agent for the box. Different surfaces, one incident stream, one API.
Chains, heartbeats and ladders
Chained calls, asserted per step
A /health endpoint proves a process answers. It proves nothing about the flow behind it. The chain runs the real calls in order and checks each response — the status code, the time it took, a value inside the JSON — as often as once a minute on every paid plan, from every location or a list of at least six.
- Up to 15 steps — GET, POST, PUT, PATCH, DELETE or HEAD, run in order
- Extract and reuse — pull a value from one response and template it into the next with
{{token}} - Assert what matters — status code, response time, a JSONPath value, a header or body text, per step
/health check answers 200 this whole time — and proves none of these four calls.
0 of 4 proven
The job that never started
A job that stops running goes silent, not red — nothing throws, so nothing alerts. Give it a heartbeat URL to ping when it runs, and the missing ping becomes the alarm: miss the window past the grace period and Uptimia opens an incident. Signal start and finish too, and it catches jobs that hang instead of stopping.
- Interval or cron schedule — a plain interval or a 5-field cron expression in your account timezone
- One line to wire in — copy-paste snippets for Crontab, Bash, PowerShell, GitHub Actions and PHP
- Catches hangs, not just misses — send a start ping and a runtime limit flags a job that never finishes
Monitors created from your deploy step
Nobody clicks anything — the script that shipped the service created its monitor. Create and manage monitors over the REST API from a CI step, and when an incident opens, a custom webhook POSTs it into whatever you already run: a status board, a bot, a ChatOps flow.
- A REST API — create, read, update and delete monitors on every plan (API monitors and heartbeats live on v2), with account API keys managed in settings
- Custom webhooks — POST a fixed JSON body with your own headers to any endpoint on a monitor event
- Safe by default — webhook delivery is TLS-verified, pins DNS at send time and rejects private-network targets
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
Slack first, PagerDuty if nobody acknowledges
In the channel your team already watches, not an inbox nobody opens at 03:00. The ladder moves an unanswered Slack ping up to a PagerDuty page on your schedule, and one acknowledgement — tapped in the alert itself, no login — pauses every pending step for everyone. Ladders and acknowledgement come with Professional and above; below that, and during the trial, every alert goes to everyone at once.
- 12 channels — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, email, SMS, webhooks and more
- Escalation ladders — up to 10 timed steps per policy; acknowledge from the alert and the ladder pauses, from Professional up
- Confirmed first — outages are verified from multiple regions — and late jobs past their grace period — before anyone is paged
Paged where you already work, not in another dashboard
A worker that stopped, a chain that broke, a box out of disk — all of it reaches the same channels, and all of it is scriptable from the REST API.
Microsoft Teams12 channels, one contact list — set it from the API or the UI, once.
Browse the full integrations directory →A broken deploy should page you.Not your users.
Every monitor type in the 30-day trial — 50 API chains, 50 heartbeats, all 12 alert channels.
Wire the first monitor in
Point it at a surface, route the alert, and let it run.
Pick the surface
An API chain, a heartbeat URL, a browser flow or the one-line agent. Create it in the UI or over the REST API.
Route the alert
Send it to Slack, Discord or PagerDuty, add a webhook, and on Professional set an escalation ladder so nothing rings unanswered.
Let it run
Checks run from 171+ locations and confirm a failure before paging you — with the step or job that broke named.
Also included
One-line server agent
CPU, memory, disk and load from inside the box — a checksum-verified bash install, no collector to write. Linux, via a systemd timer or cron.
Transaction monitoring
Replay a login or checkout in a real Chrome browser — built step by step in the builder, with a screenshot of what each step saw.
Maintenance windows
Deploying tonight? Schedule the window — checks pause, alerts stay quiet, no false page during a planned release.
Recovery notices
When a service comes back, the people who were alerted hear that too — no lingering "is it still down?" in the channel.
Incident history
Every incident is logged with what fired, when, how long recovery took and — where a ladder is running — who acknowledged it.
One list for chains and jobs
API chains, heartbeats, servers and uptime checks share one dashboard, one alerting spine and one API — not four separate tools.
What is website monitoring for developers?
Website monitoring for developers is the practice of watching the surfaces you ship — HTTP APIs, background jobs, servers and user flows — and alerting you through the tools you already use when one breaks. You wire monitoring into the stack: a multi-step API check from outside, a heartbeat ping a cron job sends in, an agent inside the box, and a REST API and webhooks where you'd rather script it.
200 OK, still broken
A shallow ping stays green while the flow your users depend on fails.
The chain catches it
The assertion that fails names the exact call — so you start debugging, not guessing.
Which monitor watches what
Each family watches a different surface — all sharing one dashboard, one alerting spine and one REST API. Each is also counted separately, and a chain is the priciest row to run: Basic carries 1 API chain and 10 heartbeats, Professional 10 and 100.
See all monitor types →| Surface | What it catches | How it works |
|---|---|---|
| API chain | Broken multi-step flows | Up to 15 ordered steps with per-step assertions, checked as often as once a minute |
| Heartbeat | Cron & workers that silently stop | Inbound ping URL; a missed window past the grace period opens an incident |
| Uptime | Outages, server errors | Outside-in checks as often as every 30 s on Professional and up, confirmed from up to 3 regions |
| Server agent | CPU, memory, disk pressure | One-line Linux agent reporting /proc + df every 30 s |
| Transaction | Broken logins & checkouts | Multi-step flows replayed in a real Chrome browser |
Developer & DevOps monitoring FAQ
01What is website monitoring for developers?+
02Can I monitor a multi-step API flow, not just one endpoint?+
{{token}}, and assert on status code, response time, a JSONPath value, a header or body text per step. If a step fails, the alert names it — you know which call broke.03How do I monitor a cron job or background worker?+
curl so it pings when it runs. Set an interval or cron schedule with a grace period, and if the ping doesn't arrive, an incident opens. A start ping plus a runtime limit also catches jobs that hang. Snippets cover Crontab, Bash, PowerShell, GitHub Actions and PHP.04Is there an uptime monitoring API to create and manage monitors?+
curl example. There's no Terraform provider or Zapier app.05Can I issue a separate API key to each team member?+
06Where do alerts go, and can I pipe them into my own tools?+
07Do you handle on-call rotations?+
08Does the server agent run on Windows?+
/proc and df for CPU, memory, disk and load. A PowerShell collector for Windows and a macOS one ship alongside it and post the same payload — minus the per-core and I/O-wait figures only Linux exposes — but they aren't handed to you as a one-liner. Windows hosts can also be watched from the outside with uptime, API or transaction monitors.09Can I import a cURL command or OpenAPI spec into the API builder?+
10How many chains, heartbeats and agents does a plan include?+
Ship it. We'll watch it.
Wire an API chain, a heartbeat and a server agent into the trial — alerts reach you where you already are.