Trial
Freefor 14 days, no card
- Monitors
- 10
- Fastest check
- 60 s
- Seats
- 3
- History
- 30 days
We check your sites from at least two locations. One failed check can't page you. A second location has to see it too.
14 days free.
No card.
| Name | Status | Type | Response time by location, last hour | Interval | 24h uptime |
|---|---|---|---|---|---|
| Checkout APIhttps://shop.example.co.uk/api/health | UP2 days | http adv | fsn1148 msnbg1139 mshel1187 ms | 30 s | 100% |
| Status APIhttps://api.example.co.uk/v2/status | DOWN4 min | http | fsn1timeoutnbg1timeouthel1timeout | 1 min | 99.7% |
| Mail servermail.example.co.uk:993 | DEGRADED12 min | imap | fsn12.4 snbg12.1 shel12.7 s | 5 min | 100% |
| Homepagehttps://example.co.uk/ | UP19 days | http | fsn188 msnbg181 mshel1117 ms | 1 min | 100% |
| Nightly backupheartbeat, grace 30 min | UP6 days | heartbeat | Last ping 03:12. Next one due by 03:42 tomorrow. | 24 h | 100% |
| Staginghttps://staging.example.co.uk/ | PAUSED3 h | http | fsn1-nbg1- | 5 min | - |
No DOWN without
a second opinion
Networks wobble. A route drops packets for a minute and comes back. If a single probe could open an incident, you'd learn to ignore your alerts. So a single probe can't.
Play both cases. In the first, Checkout API really is down. In the second, only the route from Falkenstein is broken.
| Location | Last result |
|---|---|
fsn1Falkenstein | 200 in 148 ms |
nbg1Nuremberg | 200 in 139 ms |
hel1Helsinki | 200 in 187 ms |
Checkout API is down. Confirmed from fsn1 and hel1. Timed out after 10 s on https://shop.example.co.uk/api/health.
Nothing posted. No incident was opened, so nobody was paged.
Confirmed
by hel1
Every monitor runs from at least two of them. Each one checks over IPv4 and IPv6. Failed checks record a network path trace, so you see the route the probe took and not just the word "timeout".
DE
Falkenstein
DE
Nuremberg
FI
Helsinki
More regions coming.
Websites, servers, ports, certificates, domains, mail and the cron job nobody has looked at since 2021. Every plan gets every kind.
Fetch a URL and check that it answers.
Set the method, headers and body. Look for a keyword. Write your own status rules.
Ping a host. For servers, routers and anything without a web page.
Check that a port accepts connections. Databases, SSH, game servers.
Hear about an expiring certificate before your visitors' browsers do.
Looked up once a day. A second probe confirms any change before you hear about it.
Check that your incoming mail server answers.
Check that your outgoing mail server answers.
Your cron job requests a URL each time it runs. A late ping marks it down.
30 s checks on Pro and Business
Your job requests its ping URL each time it runs. If a ping is late past the grace period, the monitor goes down. Add /fail to the URL and a failed run goes down straight away.
# run the backup, then report
./backup.sh \
&& curl -fsS -m 10 --retry 5 "$PING_URL" \
|| curl -fsS -m 10 --retry 5 "$PING_URL/fail"Add a contact once and attach it to the monitors it should hear about. Every plan gets every channel.
A phone call reads the alert out, to a mobile or a landline. Webhooks send JSON to your own HTTPS endpoint, once a DNS TXT record proves the domain is yours, so nobody can point alerts at someone else's server.
You know it's down. You're on it. One click and it stops telling you.
Every channel
on every plan
Start a maintenance window before you restart the database. Checks keep running and alerts wait.
When the window ends, anything still down alerts as normal. Anything that came back up says nothing. The buttons in the banner work, so try them.
| Monitor | Status | Alert |
|---|---|---|
| Postgres primarydb1.example.co.uk:5432 | DOWN | Held |
| Checkout APIhttps://shop.example.co.uk/api/health | DOWN | Held |
| Homepagehttps://example.co.uk/ | UP | Nothing to send |
Clicking through the dashboard is fine for five monitors. For fifty, write them down once.
Both, with an OpenAPI document for the REST side.
A status-page script doesn't need the keys to the building.
viewermemberadmin
Connect Claude or another AI assistant. Ask what's down, or have it pause a monitor before a deploy.
Providers for all three, from our own registry. Monitors go through code review with the rest of your infrastructure.
Terraform
terraform {
required_providers {
justmonitorit = {
source = "dash.justmonitorit.com/justmonitorit/justmonitorit"
}
}
}
resource "justmonitorit_contact" "ops" {
name = "Ops"
email = { address = "ops@example.com" }
}
resource "justmonitorit_monitor" "homepage" {
name = "Homepage"
interval_s = 60
locations = { regions = ["eu"] }
http = { url = "https://example.com/" }
contact_ids = [justmonitorit_contact.ops.id]
}REST
# List your monitors
curl -s \
-H "Authorization: Bearer $JMI_TOKEN" \
"https://dash.justmonitorit.com/api/v1/orgs/$ORG/monitors"
# Pause one while you work on it
curl -s -X POST \
-H "Authorization: Bearer $JMI_TOKEN" \
"https://dash.justmonitorit.com/api/v1/orgs/$ORG/monitors/$MON/pause"
# The full description
https://dash.justmonitorit.com/api/v1/openapi.jsonMCP
# Add JustMonitorIt to Claude Code
claude mcp add --transport http justmonitorit \
https://dash.justmonitorit.com/api/v1/mcp \
--header "Authorization: Bearer $JMI_TOKEN"
# Some of the tools it gets
list_monitors get_monitor_uptime
create_monitor pause_monitor
list_incidents acknowledge_incident
add_incident_note get_audit_logImport from UptimeRobot, HetrixTools or NodePing. You don't have to type everything in again.
| Selected | Found | Becomes |
|---|---|---|
| Homepage | HTTP, every 1 min | |
| Shop keyword check | HTTP Advanced, keyword | |
| mail.example.co.uk | TCP port 993 | |
| Backup cron | Heartbeat | |
| Ops email | Email contact | |
| Old staging | Not selected |
The UptimeRobot key was used for this read only. It is not saved.
Key used once.
Never stored.
We haven't set prices yet, and we won't make one up here. The plans differ in size, not features. The trial is free for 14 days and doesn't need a card.
Freefor 14 days, no card
Priceannounced at launch
Priceannounced at launch
Priceannounced at launch
Falkenstein and Nuremberg in Germany, and Helsinki in Finland. Each checks over IPv4 and IPv6. More regions are coming, and we'll list them when they're live.
When a check fails at one location and a check from another location fails too. A single failure from one place is recorded, but it opens no incident and sends no alert.
Create a Heartbeat monitor and copy its ping URL. Have the job request that URL when it finishes, or the same URL with /fail on the end when it fails. If no ping arrives within the interval plus the grace period, the monitor goes down.
14 days, no card. 10 monitors checked every minute, 10 contacts, 3 seats, 5 SMS credits and 30 days of history. Every check kind and every alert channel.
We'll publish prices at launch. Until then the pricing page shows what each plan includes.
In Germany. The database runs on a Hetzner server in Falkenstein, and its encrypted backups are kept in Nuremberg.
No. The import uses the key once to read your account, shows you what it found, and drops the key. Nothing is created until you confirm.
Add a URL, pick how often to check it, choose who hears about it.
Start your free trial