Managing monitors
A monitor watches one thing — a URL, host, port, certificate, domain or cron job. Here's how to create, tune, pause and clean up your monitors from the dashboard.
The basics
Everything starts on the Monitors page in your dashboard. Each monitor checks a single target on a schedule you choose, records the result, and raises an incident when something goes wrong. You can run as many monitors as your plan allows, each with its own type, interval and alert contacts.
Creating a monitor
From the dashboard, choose Add monitor (the /dashboard/monitors/new page). Moonitor walks you through a short form:
Choose a monitor type
Decide what you want to watch — a website, a port, a certificate, a cron job and so on. Each type asks for slightly different details. See Monitor types for the specifics of each one.
Give it a friendly name
A short label like “Marketing site” or “Nightly backup job” so you can recognise it at a glance in lists and alerts.
Enter the target
Depending on the type, this is a URL, or a host plus a port — the thing Moonitor will actually check.
Pick a check interval and timeout
How often to check, and how long to wait for a response before the check is treated as a failure.
Save
Moonitor starts checking immediately — there’s nothing else to switch on.
Tip
Got a lot to add? Monitors → Bulk add creates them from a spreadsheet instead, with a preview of exactly what will be created before anything is saved. See Bulk import.
Common fields
Whatever type you pick, these settings show up on almost every monitor:
- Friendly name — the human-readable label used in the dashboard and in alerts.
- Monitor type — what kind of check this is. This cannot be changed after creation, so pick carefully.
- Target — a URL, or a host plus a port, depending on the type.
- Check interval — how frequently Moonitor runs the check.
- Timeout — how many seconds to wait for a response (1–60, default 30). If there’s no response within the timeout, the check fails.
Check intervals
The interval is how often Moonitor runs the check. You can choose from 30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes, 15 minutes, 30 minutes and 1 hour. The fastest interval available depends on your plan:
| Plan | Fastest interval |
|---|---|
| Solo | 1 minute |
| Team | 30 seconds |
| Max | 30 seconds |
The form only offers the intervals your plan allows, and the server rejects anything faster — so you can’t accidentally exceed your limit. Need to check more often? See Plans & billing.
Tip
Start with a 5-minute interval while you’re setting things up, then tighten it once the monitor is stable and you trust it. Frequent checks are great for critical services, but they’re overkill for everything.
Monitor states
Every monitor is always in one of these states:
| State | What it means |
|---|---|
| Pending | Created but hasn't completed its first check yet. |
| Up | The last check passed. |
| Degraded | Answering, but slower than the threshold you set. Still counts as up — see below. |
| Down | The last check failed — an incident is open. See Incidents. |
| Paused | Checks are stopped and no alerts are sent. |
Slow-response alerts
A site answering in 14 seconds is having an outage as far as its users are concerned, but every check still passes. Set a threshold on a monitor and Moonitor will show it amber instead of green when it crosses that line.
Thresholds are off by default. Turn one on when editing a monitor; we’ll suggest a starting value based on that monitor’s own p95, because the right number for a static page and for a report endpoint are nothing alike.
| Setting | What it does |
|---|---|
| Threshold | The response time, in milliseconds, that counts as slow. |
| Measure | Last check uses the most recent response time. Rolling p95 is quieter on a service whose latency is naturally spiky. |
| Consecutive checks | How many in a row must cross the line before the state changes — and how many must come back under it to recover. Stops one slow check flipping your status page. |
Note
A degraded check is an upcheck. Turning this on will not move your uptime percentage by a single decimal place, historically or going forward — your SLA means exactly what it meant before. Time spent slow is reported separately, on the monitor’s page.Alerts for slow responses are opt-in per contact. On the monitor’s page, tick Also alert when it’s slow for the contacts who want them; everyone else keeps receiving down and recovery alerts only.
Evidence from a failure
When a check fails and our verification locations weigh in, Moonitor keeps what each of them actually saw: the response status, the useful response headers, the first few KB of the body, and where the time went — DNS, connect, TLS handshake, and how long the origin took to answer.
That is the difference between “your site was down for four minutes” and “Cloudflare returned 522 from Los Angeles while Helsinki got a clean 200”. It appears on the monitor’s page under the cross-check that recorded it.
Note
Captured bodies are kept for 30 days and are always displayed as plain text, never rendered. Credentials are never stored: response headers go through an allow-list, and any value you configured as a request header is redacted out of anything we keep.Reading a monitor's page
Open any monitor to see its current health and history at a glance. Here’s what each part of the page is telling you:
| On the page | What it means |
|---|---|
| Status badge | Whether the monitor is Up, Down, Pending or Paused — see monitor states above. |
| Last checked | When the most recent check ran, and how many milliseconds the target took to respond. |
| Uptime · 24 hours / 7 days / 30 days | The share of checks that passed in that window. 100% means every check passed. Each card also shows how many checks ran and how many failed. |
| Response time | A chart of how long the target took to respond over the last 60 checks. A steady climb can be an early warning that something is starting to struggle. |
| Recent incidents | The latest outages with their cause and how long each lasted — see Incidents. |
| Certificate / Domain expires | On SSL and Domain monitors, the exact date the certificate or registration runs out. |
| Heartbeat URL | On Cron / Heartbeat monitors, the unique URL your job pings — see Heartbeats & cron. |
Note
Uptime is worked out from the checks Moonitor actually ran in each window — it’s the percentage that came back healthy. A brand-new monitor shows 100% until its first failure, because every check so far has passed.
Day-to-day actions
Check now
On a monitor’s page, Check now runs an immediate check instead of waiting for the next scheduled one — handy after a deploy or to confirm a fix. The monitor must not be paused.
Pause and resume
Pausing stops checks and silences alerts; resuming picks checking back up on the next cycle. It’s the right move during planned maintenance, when you already know something will be down and don’t want the noise.
Editing
Open a monitor and choose edit. Everything is editable except the monitor type. Setting an interval below your plan’s minimum is rejected.
Deleting
Deleting removes the monitor and its entire history — check results and incidents — permanently. This cannot be undone, so delete with care.
Note
Remember: the monitor type can’t change later. If you picked the wrong type, delete the monitor and create a new one with the right type.
Monitor limits
Each plan includes a maximum number of monitors. When you reach your limit you can’t add more until you upgrade your plan or delete a monitor.
| Plan | Monitors |
|---|---|
| Solo | 20 |
| Team | 100 |
| Max | Unlimited |
See Plans & billing to compare plans and upgrade.
Bulk actions
On the Monitors list you can select several monitors at once and act on all of them in one go. Bulk actions let you:
- Set their alert contacts.
- Pause or resume them.
- Delete them.
It’s the quickest way to wire up a batch of new monitors to the same contacts, or to pause a group of related services before maintenance.