Skip to content
UpButler
ProductAgentsStatus pagesDocsPricing
Sign inStart free

Uptime monitoring that checks twice before it wakes you

Website monitoring, API monitoring and cron job monitoring in one place. Every failure is confirmed before anyone is alerted, every incident arrives with a likely cause, and your status page keeps up on its own.

Start monitoring freeRead the docs

Seven kinds of check, one model

Every monitor has the same states (up, degraded, down, paused), the same alerting and the same incident flow, whatever it checks. Pick the kind, or let UpButler infer it from what you pass.

http

Website and API checks

Status codes, keyword present or absent, JSON paths, headers, latency budgets, TLS certificate expiry. Any method, headers and body.

All plans

tcp

Port checks

Databases, mail servers, game servers: anything that should accept a connection.

All plans

dns

DNS records

A, AAAA, CNAME, MX, TXT and NS records, optionally with the values that must be present.

All plans

heartbeat

Cron and job monitoring

Your job pings a URL when it runs. No ping in time, plus grace, means down. A /fail URL reports errors immediately.

All plans

manifest

One endpoint, many components

Read a JSON health document and map each key to a status page component. Statuspage components.json works as is.

All plans

script

Multi-step API checks

Log in, create a record, read it back, clean up. Runs in an isolated sandbox.

Pro and Business

browser

Real-browser checks

Playwright drives Chromium through your sign-up or checkout and fails when the page does.

Business, up to 20 monitors

No false alarms is a feature

An alert you learn to ignore is worse than no alert. Here is what happens between a failed request and your phone buzzing.

  1. 01

    Check fails

    Timeout, wrong status, assertion miss.

  2. 02

    Re-check in 15 s

    Most blips end here, silently.

  3. 03

    Confirmed down

    After 2 consecutive failures by default.

  4. 04

    One incident

    Failures on the same page within 30 min are grouped.

  5. 05

    Reminders

    30 min, 2 h and 8 h if still down.

  6. 06

    Recovery

    Incident resolves, summary drafted.

With several regions, step 1 is a vote: see below. Thresholds are per monitor: failureThreshold from 1 to 10, recoveryThreshold for flappy services, and reminder intervals you can change or turn off. Alerts go to email, Slack, Discord, Telegram or a signed webhook.

Checked from four places, decided by majority

A route problem between one data center and your server is not your outage. Monitors can be checked from several EU locations in the same round, and the result is a vote: down only when a strict majority of the regions that answered say so, degraded on an even split, up when only a minority fails. You still see every region's latency and errors.

Free checks from 1 region, Starter from up to 2, Pro from up to 3, Business from all four. Works for HTTP, TCP, DNS and manifest monitors; the failure threshold still applies on top, round by round.

Website monitoring

A 200 does not mean the page works. Check that the words your customers need are actually on it, that the TLS certificate is not about to expire, and that it loads within your budget. On Business, a real browser can click through the flow that pays your bills.

Add statusPage and the same call puts it on your status page.

Monitor a website
curl -X POST https://upbutler.com/api/v1/services \
  -H "Authorization: Bearer $UPBUTLER_KEY" -H "Content-Type: application/json" \
  -d '{"name":"Website","url":"https://acme.com","keyword":"Add to cart","statusPage":"acme"}'
Monitor an API
curl -X POST https://upbutler.com/api/v1/monitors \
  -H "Authorization: Bearer $UPBUTLER_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "Orders API",
    "url": "https://api.acme.com/v1/orders?limit=1",
    "headers": { "Authorization": "Bearer test_…" },
    "intervalSec": 30,
    "assertions": [
      { "source": "status", "op": "eq", "value": 200 },
      { "source": "json", "path": "$.data[0].id", "op": "exists" },
      { "source": "latency", "op": "lt", "value": 800, "severity": "degraded" },
      { "source": "ssl_days", "op": "gt", "value": 14, "severity": "degraded" }
    ]
  }'

API monitoring

Send real requests with your headers and body, then assert on what comes back: status, JSON paths, headers, latency. Mark a check degraded instead of down when it is only slow. Script checks on Pro chain several requests together.

Cron job monitoring

The jobs that fail quietly are the expensive ones: backups, invoices, data syncs. A heartbeat monitor expects a ping every period. Silence past the grace window means down, and a /fail ping reports an error straight away, with no waiting.

Monitor a cron job
# 1. Create the heartbeat (or let your agent do it)
curl -X POST https://upbutler.com/api/v1/services \
  -H "Authorization: Bearer $UPBUTLER_KEY" -H "Content-Type: application/json" \
  -d '{"name":"Nightly backup","periodSec":86400,"graceSec":1800}'

# 2. Ping it from the job
30 2 * * *  /opt/backup.sh && curl -fsS https://upbutler.com/hb/<token> \
                           || curl -fsS https://upbutler.com/hb/<token>/fail

AI incident report · checkout-api

Likely causes

  • Upstream timeout: responses climbed from ~180 ms to 1.9 s a minute before the first 503.
  • The 503 body names the load balancer, not the app: the backend pool was likely empty.

Suggested next steps

  • Check the health of the checkout backend instances and recent deploys.

Public summary

Some customers cannot complete checkout right now. We are working on it and will update this page within 30 minutes.

Alerts that come with a first guess

When an incident opens, UpButler sends the relevant check context (status codes, timings, TLS and DNS details, a short response excerpt) to a language model and attaches what comes back: likely causes, next steps and a customer-safe summary. On recovery it drafts the post-incident summary.

Record deploys from CI with the API, the upbutler CLI or our GitHub Action, and the report tells you when errors started right after a release, with the version and commit.

Free includes 10 reports a month, Starter 100, Pro 1,000 and Business 5,000. It can be switched off per monitor.

Limits, plainly

Free$0

10

monitors, every 5 min, from 1 region

30 days of history

Starter$12/mo

25

monitors, every 1 min, from up to 2 regions

1 year of history

Pro$29/mo

75

monitors, every 30 s, from up to 3 regions

1 year of history · script checks

Business$99/mo

300

monitors, every 30 s, from all 4 regions

2 years of history · 20 browser checks

Commercial use is fine on every plan, and new workspaces start with 14 days of Pro. See pricing for the full list.

Uptime monitoring questions

What is uptime monitoring?

Uptime monitoring checks your website, API or server from the outside on a schedule and alerts you when it stops responding correctly. UpButler also records response times, opens incidents, updates your status page and drafts what to tell customers.

How often does UpButler check my site?

Every 5 minutes on the Free plan and every minute on Starter, and as often as every 30 seconds on Pro and Business. The default for new monitors is 60 seconds where your plan allows it.

How do you avoid false alarms?

A failed check is re-checked about 15 seconds later, and a monitor is only marked down after two consecutive failures (configurable from 1 to 10). Recovery can require several successes too. Related failures on one status page are grouped into a single incident.

Can I monitor cron jobs and background workers?

Yes, with heartbeat monitors. Your job requests a unique URL each time it runs; if no request arrives within the expected period plus a grace period, the monitor goes down. Calling the /fail URL reports an error immediately.

Where do alerts go?

Email, Slack, Discord, Telegram and webhooks signed per the Standard Webhooks spec. On the Business plan, weekly on-call rotations and escalation policies page whoever is on call by email or Telegram until someone acknowledges; acknowledging works on every plan. There are no SMS or phone-call alerts; forward the webhook to a paging tool if you need them.

Do you check from multiple regions?

Yes, from four EU locations: Helsinki, Nuremberg, Falkenstein and Lauterbourg. HTTP, TCP, DNS and manifest monitors can use 1 region on Free, 2 on Starter, 3 on Pro and all of them on Business. A monitor only goes down when a strict majority of the regions that reported agree; if exactly half fail it is marked degraded instead. A region whose probe is unhealthy is left out of the vote, never counted as a failure.

Can I monitor APIs that need authentication?

Yes. Set any method, headers and body, and assert on the status code, JSON fields, headers and latency. For multi-step flows such as log in then fetch, use script checks on Pro and Business.

Your first monitor takes one call.

Or one sentence to your agent. Free for 10 monitors, no card required.

Start freeMonitoring docs