Changelog

Pages now fit a phone's screen. Nothing changes on a laptop or desktop.

• The menu behind the navbar's button is compact: the pages in a grid, then your organisation, Maintenance, Theme, Account and Logout, each with its name. Its menus open over the page.
• Tables keep readable columns and scroll sideways, with a shadow at the edge when more is off screen. The hops of a trace under Network path, email addresses, names and errors no longer break every few letters.
• A monitor's page shows its type, interval and timeout on one line and its address under them, with smaller Pause, Edit and Delete buttons.
• The tabs on Settings stay on one row that scrolls, with the current tab in view.
• An incident's timeline puts each time above its text, and Check every shows four choices a row.

The app now looks like the pictures of it on justmonitorit.com: the same typeface, violet surfaces in the dark theme, hairline tables, and status badges with a dot before the text.

• Monitors shows each location's response time over the last hour as a small line, with its newest result beside it: red for an error, amber when slow. Failed minutes show in red at the top of the line. A heartbeat shows when it last pinged and when the next ping is due. On a phone each monitor is a card.
• Monitor types and contact channels have new icons. Add new monitor and Add new contact show every type in one grid you can click anywhere on, and the monitor form picks the interval with a row of buttons under Check every.
• Contacts shows each contact's address under its name.
• An incident's timeline marks each step with a coloured dot: red for failures, green for recovery, blue for alerts and notes.
• While a maintenance window is active, a card with hazard tape at the top of every page says what is held and until when, with +30 min and End now.
• The sign-in pages sit on the brand's pink.

The row's Info button on Monitors is gone: click the monitor's name. The REST API has a new endpoint for the lines, GET /orgs/{org}/monitors/sparklines (see the REST reference).

justmonitorit.com now has pages about the product. They show how a second location confirms a failure before anyone is alerted, list every monitor kind and alert channel on Features, and compare the plans' limits on Pricing. We announce prices for the paid plans at launch, and the 14-day trial needs no card.

Our probes' User-Agent links to justmonitorit.com/probe, which tells the owner of a server we check what the requests are and how to ask us to stop.

When many of your targets went down at once, for example when a server that hosts many websites restarted, we could take one of our own check locations out of service because it saw so many failures. Some of your monitors then showed no data while they were down. Failures now count against a location only when the other locations do not see them. Failures that every location sees are your outage, and alerts go out as usual.

Alerts can now go to a Microsoft Teams channel. Someone who can add workflows to the channel, often your IT team, opens the channel's ... menu, chooses Workflows, picks Send webhook alerts to a channel and copies the link it shows. In Contacts → Add new contact choose Microsoft Teams and paste that link. We post a 6-digit code to the channel; enter it on the contact's page to start alerts. A Teams workflow does not tell us whether its post arrived, so the code is how we know the channel gets them.

Each alert is a card with the monitor's name and state, what went wrong, the target, the locations that see it and when it started, and an Open incident button. Recoveries, slow responses, expiring certificates and domains, and digests get their own cards.

Old Office 365 connector links (webhook.office.com) stopped working when Microsoft retired them in May 2026 and are refused; ask for a Workflows link instead.

Teams contacts are in the API (kind: "teams", secret: {"webhook_url"}), GraphQL, the MCP server, and the Terraform, OpenTofu and Pulumi providers (a teams block). The UptimeRobot and HetrixTools imports now bring Teams workflow links across as Teams contacts, and post their codes to the channels as they are created.

Alerts can now come as a phone call. In Contacts → Add new contact choose Phone call and enter the number in international format. It can be a mobile or a landline, in the same countries as SMS. We call the number once and read out a 6-digit code to verify it. After that, each alert is a call that reads out the monitor, what failed and how many locations see it, then reads it again. Recoveries, slow responses and expiring certificates and domains are read out the same way.

A call uses 2 of your plan's monthly SMS credits, or 4 outside the UK, Ireland, the US and Canada. Numbers that cost more to call use more, up to about 20 credits a call; the contact's page shows how many. When the credits run out, alerts go by email to the organisation's owners and admins, as they do for SMS. If the last 3 calls ring out, are busy or fail, we email the owners and admins.

Phone call contacts are in the API (kind: "voice", config: {"phone"}), GraphQL, the MCP server, and the Terraform, OpenTofu and Pulumi providers (a voice block). The NodePing and UptimeRobot imports now bring voice contacts across as phone call contacts.

A heartbeat monitor watches a job that runs on a schedule, such as a backup or a cron script. Choose Heartbeat when you add a monitor, set how often the job runs (Expected every, 1 minute to 7 days) and how late it may be (Grace, default 5 minutes). The monitor's page then shows its Ping URL: have the job request it each time it finishes, for example curl -fsS -m 10 --retry 5 -o /dev/null <ping URL>. GET, HEAD and POST all work. To report a failed run, request the same URL followed by /fail.

When no ping arrives within the period plus the grace, or the job reports a failure, the monitor goes DOWN and its contacts are alerted, and the next successful ping brings it back UP. Recent pings on the monitor's page lists the newest pings with their address and client. Nothing is checked from our locations, and a new heartbeat does not alert until its first ping. If our service is unavailable for a while, a job gets a full period and grace after we are back before a missed ping counts.

Heartbeats are in the API (kind: "heartbeat", with ping_url in the response and the ping history at GET .../monitors/{id}/pings), GraphQL, the MCP server, and the Terraform, OpenTofu and Pulumi providers (a heartbeat block and a ping_url attribute). Only members and above see a monitor's ping URL.

Hold alerts during planned work and get them afterwards only for what is still broken. Schedule a window on the new Maintenance page (the bell in the navbar, then Schedule maintenance…) for all monitors or the ones you pick, starting now or later, for up to 7 days. To mute everything at once, the same menu has Mute alerts of all monitors for 30 minutes, 1, 2 or 4 hours.

During a window, monitors keep checking and incidents are recorded as usual, but nobody is alerted. A banner on every page shows when alerts are held until, with +30 min and End now. Ten minutes before the end, whoever scheduled it gets an email if a monitor is still down. When it ends, each incident that is still open alerts its contacts once, with the time it started; incidents that ended inside the window send nothing. The API has the same operations under /orgs/{org}/maintenance.

Alerts can now go to a Slack channel. In Slack, add an incoming webhook for the channel, then in Contacts → Add new contact choose Slack and paste its URL. We check the webhook with Slack when you save, without posting anything, and the contact is active at once. Each alert is one message with the monitor, what failed, where, and a link to the incident.

A webhook contact posts each alert as JSON to an HTTPS endpoint of yours, for your own tooling or an automation service. Choose Webhook in Contacts → Add new contact and give the URL, with a token in it that your endpoint checks. To prove the domain is yours, add the TXT record the contact page shows to your DNS, then press Check again; nothing is sent until we find it. The JSON format, retries and how we read your response: Webhooks.

Settings → Import → UptimeRobot brings your monitors and alert contacts over with an UptimeRobot API key (the main or the read-only one). HTTP, keyword, ping and port monitors are mapped to their JustMonitorIt kinds, with their interval, timeout, regions and alert delay, and a domain expiry reminder becomes a domain expiry monitor. Email, SMS and Discord alert contacts become contacts.

You review everything before anything is created. Items that cannot be imported, such as heartbeat monitors or Slack integrations, are listed with the reason. UptimeRobot does not share Pushover or PagerDuty keys, so add those contacts by hand. The key is used once and never stored.

Manage monitors and contacts as code. Add the provider with source = "dash.justmonitorit.com/justmonitorit/justmonitorit" and an API token with the member role, and describe monitors (every kind) and contacts (every channel) in Terraform or OpenTofu. Changes made in the web app show up in terraform plan, and existing monitors can be imported. Pulumi has the same resources through its own plugin. Set-up, examples and how secrets are handled: Terraform and Pulumi.

On an existing HTTP Advanced, IMAP or SMTP monitor, unticking Warn when the certificate expires soon and saving turned the warning back on at 14 days. It now stays off. In the API, "cert_expiry_warn_days": null in a PATCH of such a monitor turns the warning off; before, it reset it to 14.

The REST reference and the OpenAPI document now describe the spec of each monitor kind field by field, with its limits and default, instead of as a free-form object. A request takes the MonitorSpecInput schema of the monitor's kind, and a response returns the MonitorSpec schema. The x-jmi-spec-by-kind member lists which schema goes with which kind, so OpenAPI code generators can build a typed model for each one. The MCP create_monitor tool describes the same fields to AI assistants.

Domain expiry monitors now look the domain up once a day, from one of our locations at a time, taking them in turn. Registries limit how often they answer, and asking from several locations at once got some lookups refused, which left monitors showing NO DATA. A lookup the registry refuses is tried again from another probe.

A new monitor looks its domain up straight away. Before you are alerted that a domain is expiring, has expired or was renewed, a second probe confirms it, from another location when one is available. Existing domain expiry monitors have moved over on their own. Their location and threshold settings no longer apply, and the edit form no longer shows them. On the monitor page, Lookups lists the latest lookups and why any of them failed.

PagerDuty is a new contact type. Under Contacts, add a PagerDuty contact with a service's Events API v2 integration key and its region (US or EU). When one of its monitors alerts (down, degraded or flapping), the contact opens an incident in that PagerDuty service, and the recovery resolves it. Keep Recovered ticked so incidents close on their own.

PagerDuty cannot check a key without opening an incident, so use Send test alert after adding the contact or changing its key.

Domain expiry monitors now work for domains under .ac, .ag, .bz, .gi, .io, .lc, .me, .mn, .sh and .us. Their registries publish expiry dates but are not in IANA's list of registry servers, so we look them up directly.

When you sign up and verify your email, your organisation now gets an email contact for that address, with Add to new monitors on. Every monitor you create alerts you from the start, without adding a contact first. You can edit or remove the contact under Contacts. Existing accounts and people invited to an organisation are unchanged.

You can now automate JustMonitorIt. Create an API token under Settings → API tokens and use it with any of three APIs, which all do the same things:

• REST at /api/v1, for scripts and integrations.
• GraphQL at /api/v1/graphql, when you want several things in one request.
• MCP at /api/v1/mcp, so an AI assistant such as Claude Code or Cursor can list your monitors, pause them during a deploy or acknowledge an incident.

A token belongs to one organisation and has a role: viewer (read only), member (also changes monitors, incidents and contacts) or admin (also members and the audit log). It can never do more than the person who made it. You see the secret once, and you can give it an expiry and revoke it at any time.

Settings → API playground runs REST and GraphQL requests as you, so you can try a query before you write code. The API documentation has a quick start, recipes in curl, Python and JavaScript, and a full reference. For language models it is also at llms.txt.

Settings → Import → HetrixTools brings your monitors and contact lists over with a HetrixTools API key. Website, ping, service and SMTP monitors are mapped to their JustMonitorIt kinds, and a domain expiry warning becomes a domain expiry monitor. Email, SMS, Pushover and Discord destinations become contacts, with duplicates across lists merged into one.

You review everything before anything is created. Items that cannot be imported, such as heartbeat monitors or Slack destinations, are listed with the reason. The key is used once and never stored.

Settings → Import → NodePing moves your checks and contacts from NodePing. Paste a NodePing API token, or upload the JSON files NodePing exports. The token route also reads notification profiles, so each imported monitor alerts the same people it did in NodePing.

The review lists every check and contact with a tick box, and notes where the imported monitor will differ from the original (for example an interval rounded to one we offer). Running the import again is safe. Email, SMS and Discord contacts you already have are linked, not created twice, and monitors you already have are left unticked. Pushover contacts cannot be matched, so a duplicate is refused instead.

Sign in with your device's fingerprint, face or PIN instead of a password. Add a passkey under Account → Security, then choose Sign in with a passkey on the login page. You can have up to 10, and we email you whenever one is added or removed.

Four new monitor kinds:

• SSL expiry warns before a certificate runs out (14 days by default) and goes down once it has expired or the TLS handshake fails.
• Domain expiry checks the domain's registration with its registry every hour and warns 30 days before it lapses.
• IMAP and SMTP check that your mail server answers and replies to a command, without logging in. With TLS on, they also check the handshake and can warn before the certificate expires.

The expiry date shows on the monitor page, and alerts say how many days are left.

When a monitor goes down, up to eight of the failing locations now run an MTR to the target. The results fill in on the incident page under Network path, with a line saying where the path stopped, for example "nothing answered after hop 9". A location runs at most one automatic trace per monitor every 10 minutes.

You can also run a traceroute or MTR yourself from the monitor page. Domain expiry monitors ask a registry rather than your host, so they have no trace.

The dashboard follows your system's light or dark setting. To pick one yourself, use the theme menu in the navbar (Light, Dark or System). Charts and status colours are tuned for both.

The dashboard is rebuilt. Pages now render on our servers and update in place as you move around, and live status changes arrive without a reload. Your bookmarks and email links still work, and you stay signed in.

We fixed the findings of a security audit across the dashboard, the API, the probes and alerting. Two of them change what you see:

• Unsubscribe links in alert emails sent before 13 October no longer work. Use the link in a newer email, or edit the contact.
• Monitor names can no longer contain control characters or text-direction marks. Existing names are unchanged.