Know when it's down, and why

Maple checks your sites, APIs, ports and cron jobs around the clock. When one fails, you get the alert with the reason, and a failed HTTP check opens as a trace of the request inside your app.

Start free trial

In motion

Your monitors, live

Every bar is one check. By default, two failures in a row open an incident and alert your team. It closes on its own once the check passes again.

uptime · 5 monitors LIVE

status monitor checks p95 30d

checkout-api GET /health · every 30s 212 ms 99.71%

UP auth GET /v1/session · every 60s 84 ms 99.98%

UP postgres-primary TCP db.internal:5432 · every 30s 3 ms 100%

UP acme.com MX DNS MX acme.com · every 5m 21 ms 100%

UP nightly-backup cron 0 3 * * * · grace 15m n/a 100%

incident opened 14:32:07

checkout-api is down

Status 503, expected 2xx · failed 2 checks in a row

trace 7c1e40a9…e21f service checkout sent to #oncall

failed checks · closes when it passes again http checks carry a trace id

trace 7c1e40a9…e21f 503 · 5.02 s

maple-uptime GET /health 5.02 s

checkout GET /health 4.94 s

checkout pg.pool.acquire 4.90 s

checkout redis GET flags 3 ms

maple.uptime.failureStatus 503, expected 2xx

http.response.status_code503

maple.uptime.monitor_namecheckout-api

url.fullhttps://checkout.acme.dev/health

Root cause

See why it failed, not just that it failed

Most uptime tools stop at "503". Maple's HTTP checks carry a trace ID into your app, so if the app is instrumented, a failed check opens as the full request. Here, the database pool took five seconds to hand out a connection.

Nothing new to learn: HTTP, TCP and DNS checks are stored like any other request. Search them, chart them and alert on them with the tools you already use.
Tied to your services: Link a monitor to a service and its checks show up on that service's page, next to its errors and deploys.
Your service map stays clean: Checks never show up as a caller on your service map, so your real dependencies stay easy to read.

What it does

What you can monitor

Websites and APIs: Check the status code, response time, body text, JSON fields or headers. Anything other than a 2xx counts as a failure unless you say otherwise.
Databases and other ports: Make sure Postgres, Redis, a message broker or a mail server still accepts connections.
DNS records: Catch a missing or changed A, AAAA, CNAME, MX, TXT or NS record before your users do.
Cron jobs and workers: Your job pings a URL when it finishes. If the ping doesn't arrive on schedule, Maple alerts you.
As often as every 30 seconds: Check every 30 seconds or once an hour, and decide how many failures it takes to alert, from 1 to 10.
Set up by your AI agent: Agents can create and update monitors through Maple's MCP server, for example right after shipping a new endpoint.

Know when it's down, and why

Your monitors, live

See why it failed, not just that it failed

What you can monitor

Related features

Alerting

Distributed Tracing

Service Catalog & Map

API Performance

Point OTLP at Maple.