JustMonitorIt home

Down means down.

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.

Monitors6 monitors
NameStatusTypeResponse time by location, last hourInterval24h uptime
Checkout APIhttps://shop.example.co.uk/api/healthUP2 dayshttp adv
fsn1148 msnbg1139 mshel1187 ms
30 s100%
Status APIhttps://api.example.co.uk/v2/statusDOWN4 minhttp
fsn1timeoutnbg1timeouthel1timeout
1 min99.7%
Mail servermail.example.co.uk:993DEGRADED12 minimap
fsn12.4 snbg12.1 shel12.7 s
5 min100%
Homepagehttps://example.co.uk/UP19 dayshttp
fsn188 msnbg181 mshel1117 ms
1 min100%
Nightly backupheartbeat, grace 30 minUP6 daysheartbeatLast ping 03:12. Next one due by 03:42 tomorrow.24 h100%
Staginghttps://staging.example.co.uk/PAUSED3 hhttp
fsn1-nbg1-
5 min-

No DOWN without
a second opinion

  • Private beta
  • Checks from Falkenstein, Nuremberg and Helsinki
  • Hosted in the EU
  • Written in Rust

One failed check is a rumour. Two is an outage.

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.

Checkout APIUPIncident resolved after 19 min
LocationLast result
fsn1Falkenstein200 in 148 ms
nbg1Nuremberg200 in 139 ms
hel1Helsinki200 in 187 ms
  1. fsn1 failedTimed out after 10 s. No incident yet.
  2. hel1 checks againA second location has to see the failure before anything opens.
  3. Confirmed down, incident openedhel1 timed out too. A network path trace is saved with the incident.
  4. Slack alert sentPosted to #ops, and an email to on-call.
  5. Acknowledged by SamReminders stop. The incident stays open until checks pass.
  6. ResolvedUp from all three locations. Down for 19 min 41 s.
JustMonitorIt#ops, 14:02

Checkout API is down. Confirmed from fsn1 and hel1. Timed out after 10 s on https://shop.example.co.uk/api/health.

Confirmed
by hel1

Three locations. All in the EU.

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

    Germany fsn1

  • DE

    Nuremberg

    Germany nbg1

  • FI

    Helsinki

    Finland hel1

  • More regions coming.

    We'll add them here when they're live, not before.

Nine ways to find out something broke.

Websites, servers, ports, certificates, domains, mail and the cron job nobody has looked at since 2021. Every plan gets every kind.

Add new monitorChoose what to check.

HTTP

Fetch a URL and check that it answers.

HTTP Advanced

Set the method, headers and body. Look for a keyword. Write your own status rules.

ICMP ping

Ping a host. For servers, routers and anything without a web page.

TCP port

Check that a port accepts connections. Databases, SSH, game servers.

SSL certificate

Hear about an expiring certificate before your visitors' browsers do.

Domain expiry

Looked up once a day. A second probe confirms any change before you hear about it.

IMAP

Check that your incoming mail server answers.

SMTP

Check that your outgoing mail server answers.

Heartbeat

Your cron job requests a URL each time it runs. A late ping marks it down.

Check every30 s1 min2 min5 min10 min15 min30 min60 min

30 s checks on Pro and Business

Heartbeats work the other way round.

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"

Every kind in detail

Nine ways to get the bad news.

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.

Acknowledge it, and the reminders stop.

You know it's down. You're on it. One click and it stops telling you.

Contacts8 contacts
  • On-call emailoncall@example.co.ukVerified
  • Sam, SMS+44 7700 900123Verified
  • Sam, phone call+44 7700 900123Verified
  • PushoverOps devices4 monitors
  • Discord#status2 monitors
  • PagerDutyEU service6 monitors
  • Slack#ops6 monitors
  • Ops webhookhttps://hooks.example.co.uk/jmiDomain proved
_justmonitorit.hooks.example.co.uk TXT "justmonitorit-webhook-verification=0123…cdef"

Every channel
on every plan

Planned work shouldn't page anyone.

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.

Database upgrade. Alerts held until 14:30.3 monitors in this window. Started 13:30 by Priya.
MonitorStatusAlert
Postgres primarydb1.example.co.uk:5432DOWNHeld
Checkout APIhttps://shop.example.co.uk/api/healthDOWNHeld
Homepagehttps://example.co.uk/UPNothing to send

Your monitors, in code.

Clicking through the dashboard is fine for five monitors. For fifty, write them down once.

  • REST and GraphQL API

    Both, with an OpenAPI document for the REST side.

  • Tokens with roles

    A status-page script doesn't need the keys to the building.

    viewermemberadmin

  • MCP server

    Connect Claude or another AI assistant. Ask what's down, or have it pause a monitor before a deploy.

  • Terraform, OpenTofu and Pulumi

    Providers for all three, from our own registry. Monitors go through code review with the rest of your infrastructure.

Read the API docs

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.json

MCP

# 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_log

Moving in? Bring your monitors.

Import from UptimeRobot, HetrixTools or NodePing. You don't have to type everything in again.

  1. Paste an API key from your old tool.We use it once to read your setup. We never store it.
  2. Review what we found.Nothing is created until you've looked through the list.
  3. Import.Your monitors start running from the EU locations.
ImportReview before anything is created
UptimeRobotHetrixToolsNodePing
SelectedFoundBecomes
HomepageHTTP, every 1 min
Shop keyword checkHTTP Advanced, keyword
mail.example.co.ukTCP port 993
Backup cronHeartbeat
Ops emailEmail contact
Old stagingNot selected

The UptimeRobot key was used for this read only. It is not saved.

Key used once.
Never stored.

Plans. Prices at launch.

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.

Trial

Freefor 14 days, no card

Monitors
10
Fastest check
60 s
Seats
3
History
30 days
Start free trial

Starter

Priceannounced at launch

Monitors
20
Fastest check
60 s
Seats
3
History
90 days

Pro

Priceannounced at launch

Monitors
100
Fastest check
30 s
Seats
10
History
365 days

Business

Priceannounced at launch

Monitors
500
Fastest check
30 s
Seats
25
History
730 days
  • Every check kind
  • Every alert channel
  • Passkeys
  • Dark theme
  • Audit log
Compare every limit

Fair questions.

Where do the checks run from?

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 does a monitor count as down?

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.

How do I monitor a cron job?

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.

What does the trial include?

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.

How much will it cost?

We'll publish prices at launch. Until then the pricing page shows what each plan includes.

Where is my data kept?

In Germany. The database runs on a Hetzner server in Falkenstein, and its encrypted backups are kept in Nuremberg.

Do you keep my UptimeRobot, HetrixTools or NodePing key?

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.

Just monitor it.

Add a URL, pick how often to check it, choose who hears about it.

Start your free trial