Uptime

Uptime (/uptime) checks your targets from outside — the way a visitor on the Internet reaches them. A control-plane prober dials each monitor on a schedule, opens an incident when it goes down (after confirming), and alerts you through the channels you already connected. It’s an account-level page covering your whole fleet, and it’s available on all plans.

Uptime vs. server monitoring

These answer different questions — keep them separate:

	Server monitoring	Uptime (this page)
Vantage	Inside the box — the agent reads /proc	Outside — synthetic check from the network
Question	”How loaded is the box?” (CPU/RAM/disk)	“Is the site up, from the Internet?”
Catches	High load, full disk, a service down on the box	Whole-box/network outages, DNS/TLS/CDN failures

Note

When a whole VPS goes down, the agent goes down with it — so it can’t report its own site as down. That dead-man case is exactly the one uptime monitoring is built to catch, which is why the check runs from the control plane, not the agent.

Add a monitor, step by step

1. Click Add monitor to open the drawer.
2. Give it a Name and pick a Check type:

   Type	What it does	Example target
   HTTP	GET the URL, check the status code (and an optional body keyword)	https://example.com
   TCP	Open a TCP connection to a host and port	db.example.com:5432
   Ping	ICMP echo to a host or IP	example.com

3. Enter the target (the field relabels to URL / Host:port / Host or IP for the type you picked).
4. Set the Interval — every 30s, 1m, or 5m.
5. For HTTP, optionally set the Expected status (defaults to 200) and a Body must contain keyword — the check only passes when both match.
6. Under Alert channels, pick which connected destinations should be notified when this monitor goes down. No channels yet? The picker links you to connect one first.
7. Save. The monitor starts as Pending until its first check lands, then shows a live tick-and-latency chart and an uptime percentage.

You can point a monitor at any public URL — including sites that aren’t hosted on MZPanel.

Scan & add

Instead of typing each one, click Scan & add to discover monitorable targets across your fleet — sites, Docker apps, each server’s HTTPS port and ping, plus domains from your connected DNS zones. Externally reachable targets are preselected; tick the ones you want and add them all at once.

What else you can do

The page is a searchable list of monitor cards with compact fleet stats up top (overall uptime for the window, up/down counts).

• Filter and search — the Filter popover narrows by Status (up / down / paused / pending), Type (HTTP / TCP / Ping) and Time window (24 hours, 7 days, 30 days, 90 days); the search box matches name and target. Click the down stat to jump straight to failing monitors.
• Check now — force an immediate probe. If it fails, a diagnostics panel opens inline right under the monitor showing exactly which layer broke (DNS → TCP → TLS → HTTP), so you see the “why” the instant you click.
• Pause / resume, Edit, and Delete a monitor. Deleting removes its check history and incidents and pulls it from the status page.
• Incident history — a timeline card of every incident, ongoing ones first. Expand a row to see the captured diagnostics and, when other online agents could confirm, a multi-vantage breakdown (“down from where?”).
• Alert channels — the account-level destinations that receive alerts, with a Send test on each and a shortcut to manage them.
• Status page — configure a public availability page (see Gotchas — publishing is preview-only today).

How it works

Uptime is a control-plane feature — nothing runs on your servers. State lives in Postgres and drives the dashboard through the /v1/uptime API.

• The prober is a worker in the API. Every ~15 seconds it wakes, selects the monitors that are due (never checked, or older than their interval), and probes each one — an HTTP GET (following redirects, catching redirect loops), a TCP connect, or a system ping. It sends a stable User-Agent (MZPanel-Uptime/1.0) so you can allowlist it.
• Every probe is stored as a row (status, response time, error). Uptime percentages, the tick bar and the latency chart are computed on read from those raw rows.
• Incidents use N-strikes. A single failed check doesn’t page you — a brief blip on the prober’s side shouldn’t either. The monitor only flips to down after 2 consecutive failures, which opens an incident and delivers to its channels. When the target recovers, the incident resolves and a recovery notice goes out.
• On the down transition, two cheap extras fold into the alert: a diagnostics bundle (which layer failed and a hint) and a multi-vantage second opinion — the prober asks a few of your own online agents to reach the same target, so it can tell a real destination outage (“down for everyone”) apart from a prober-path-only glitch (“reachable from other vantages”).
• Alert channels are shared, configured once under Advanced → Integrations → Chat & Alerts (/connect/channels) and reused everywhere — uptime, per-server alerts, backups and deploys all route to the same connected destinations (Email, Telegram, Slack, Discord, MS Teams, Google Chat, generic webhook). Credentials are encrypted at rest; only the last few characters are shown back.

API & automation

Uptime is a control-plane surface, not something on a single box, so the on-box mz CLI does not apply here. Everything the page does is backed by the /v1/uptime REST API — list and create monitors, force a check, read incidents, and manage the status page — available for scripting on the Max plan.

See the API reference for endpoints and authentication.

Gotchas & troubleshooting

• Public status page publishing is preview-only. You can set an address (<slug>.uptime.mzpanel.com), toggle visibility, choose which monitors appear, and preview it live from your real data — and the config is saved. But the public URL is not served yet; the page lives in the dashboard for now. Treat it as a preview.
• Long windows only reflect recent data. Raw checks are kept for about 7 days, so the 30d and 90d uptime figures currently cover only that window until longer-term rollups land. The 24h and 7d numbers are exact.
• The prober is the “outside” — not your box. A monitor going down means the target is unreachable from the control plane; that’s the point. Use the per-incident multi-vantage panel to see whether your own servers can still reach it.
• Fresh monitors read “Pending.” A monitor shows no percentage and a full grey tick bar until its first scheduled check completes. Use Check now to probe immediately.
• HTTP checks are strict by design. The check passes only when the status code matches Expected status (default 200) and the optional keyword is present. A site returning 301/302 to its canonical URL is followed; a redirect loop or too many hops is reported as down.
• Scan & add marks some targets “internal.” Discovered Docker ports that may be bound to localhost are flagged not-reachable and left unticked — verify they’re publicly exposed before monitoring them.

Related

• Server monitoring — the inside view (CPU, RAM, disk, services).
• Local & offsite backups — another fleet-wide job that uses the same alert channels.
• API reference — automate monitors and incidents.