Guides on Tenpm Uptime Docs

Shared vs. private monitors, and restricted checks

Mon, 01 Jan 0001 00:00:00 +0000

Shared vs. private monitors, and restricted checks#

This page ties together three ideas that show up throughout the other guides: what a private monitor is versus a shared one, what makes a check restricted, and how the two interact when you’re deciding what runs where.

Private monitors: yours, on your own terms#

A private monitor is one you enrolled yourself — the agent binary running on hardware you control. It has no restrictions placed on it by Tenpm Uptime: if it can reach 10.0.0.5 or an internal admin panel, that’s the product working as intended. The blast radius of that reach is entirely your own network, so there’s nothing for the platform to guard against here.

Writing checks

Mon, 01 Jan 0001 00:00:00 +0000

Writing checks#

Creating your first check covers the basics: a name, a target, and a schedule. This guide covers the rest of the check form — the options that decide exactly what “healthy” means for a given target, and when you’re told about it.

If instead you want to be alerted when your own system stops calling us — a cron job, a backup script — that’s a heartbeat check, not one of these.

Heartbeat checks

Mon, 01 Jan 0001 00:00:00 +0000

Heartbeat checks#

An ordinary check is polled: a monitor dials your target on a schedule and reports what it found. A heartbeat is the reverse. Your system calls a URL that Tenpm Uptime gives it, on a schedule, and you’re alerted when the calls stop.

That makes it the right tool when there’s nothing for a monitor to dial:

A cron job or backup script — call the URL when the job finishes. If the job fails, hangs, or never starts, the call never happens and you’re told.
An Uptime Kuma (or similar) running on an internal network that can reach out to the internet but can’t be reached from it. Point an HTTP(s) monitor in Kuma at your heartbeat URL; each time Kuma runs it, that’s a heartbeat. If Kuma or its network goes quiet, you hear about it.
Any system that can make an HTTP request when something happens.

No monitor is involved anywhere. A heartbeat is never assigned to one, and nothing about it is sent to any monitor.

Notification channels

Mon, 01 Jan 0001 00:00:00 +0000

Notification channels#

A notification channel is a destination an alert can be sent to. Your organisation can have any number of them, and each check or monitor decides which of them it actually uses.

Adding a channel#

From Organisation settings, under Notification channels:

Add ntfy channel — sends a push notification via ntfy to a topic you choose.
Add email channel — sends to a single email address.
Add webhook channel — sends an HTTP POST with a plain JSON body of your own to any endpoint you control. See Webhook channels below for the payload shape and how to verify it came from tenpm uptime.
Add Slack channel — sends to a Slack incoming webhook. See Slack channels below.

How many channels you can have, and which kinds, depends on your plan — a kind your plan doesn’t include shows a disabled Upgrade to enable button. See Plans and billing.

Managing monitors

Mon, 01 Jan 0001 00:00:00 +0000

Managing monitors#

The Monitors page lists every monitor available to your organisation — the ones you’ve enrolled yourself, plus the shared fleet if you’re using it.

Adding more monitors#

Each additional monitor needs its own enrollment token. On the Add a monitor page, give the token a label (e.g. “home NAS”) so you can tell which agent it belongs to, and create it. One token per machine means you can revoke a single agent’s ability to (re-)enroll without touching anyone else’s.

Organisation and account settings

Mon, 01 Jan 0001 00:00:00 +0000

Organisation and account settings#

Tenpm Uptime has two separate settings pages: Account settings for you personally, and Organisation settings for things every member of your org shares. Both — along with Plan and Billing — are in the menu under your email address in the top right of the navigation bar.

Account settings#

Display timezone — timestamps on results and notifications pages show alongside UTC in this timezone. Leave it on Server default to use whatever the server itself is configured with.

Members and invitations

Mon, 01 Jan 0001 00:00:00 +0000

Members and invitations#

An organisation can have more than one person in it. Everyone in the organisation sees the same checks, heartbeats, monitors, notification channels and results, and can change any of them. The one exception is who is in the organisation, which only its owner can change.

The owner is the account that created the organisation at signup. Ownership can’t be transferred yet, and the owner can’t be removed from their own organisation.

Public status page

Mon, 01 Jan 0001 00:00:00 +0000

Public status page#

A public status page is a page anyone can open, with no login, showing whether the things you choose to publish are up. It’s for your customers or team to check “is it down, or is it just me?” without asking you.

It’s off by default, and publishing is a deliberate two-step choice: you turn the page on for the organisation, and then you opt in each individual check you want listed on it.

Plans and billing

Mon, 01 Jan 0001 00:00:00 +0000

Plans and billing#

Every organisation is on a plan, which sets what it’s limited to. Your own monitors are unlimited on every plan — plans meter checks, not agents.

The current prices are on the pricing page. This page covers what each plan’s limits are and what happens when they bite.

What each plan includes#

	Free	Solo	Double	Team
Checks	10	20	40	100
Heartbeat checks	1	5	10	25
Shortest check interval	2 min	1 min	45 s	30 s
Longest check timeout	10 s	30 s	45 s	60 s
Notification channels	2	5	10	Unlimited
Channel types	ntfy, email	ntfy, email	+ webhook	+ Slack
Members	1	1	2	Unlimited
Certificate-expiry warnings	No	Yes	Yes	Yes
Public status page	No	Yes	Yes	Yes
Result history	30 days	6 months	9 months	12 months

A few notes on the rows:

Check history and charts

Mon, 01 Jan 0001 00:00:00 +0000

Check history and charts#

Click through from the Dashboard to a check’s own page for its full history: a response-time chart, an uptime table, and individual recent results.

Time range#

The chart has a range picker: 1h, 24h, 7d, 30d, 6mo, 12mo, all. Your choice carries through everything else on the page — paging through recent results or switching which monitor you’re looking at won’t reset it.

Longer ranges use pre-aggregated hourly or daily data rather than every raw result, which changes what the Max / Min / Avg caption under the chart means: at 1h/24h it’s computed from actual response times; at 7d and beyond, each point is an average across every attempt in that period — including failed ones, since aggregated data has no separate record of which attempts actually got a response back. A response time of 0 always means the target sent nothing back at all (timeout or connection failure), not a genuinely instant response.

Private-definition checks

Mon, 01 Jan 0001 00:00:00 +0000

Private-definition checks#

An ordinary check’s URL, match rule, headers, and other details live on the server, which is what lets the server show them to you, run Test on demand, and hand them to any monitor you assign. Sometimes that’s the wrong trade — the target is an internal admin URL with credentials baked in, say, and you don’t want that sitting on a server at all, even one you trust.

Running the monitor as a service

Mon, 01 Jan 0001 00:00:00 +0000

Running the monitor as a service#

Running monitor in a foreground terminal is fine for trying it out, but for anything ongoing you want it to survive reboots, restart itself if it crashes, and log somewhere you can check later. Two straightforward ways to get that: a systemd unit, or a Docker container. Pick whichever fits how you already manage the machine it’ll run on.

Either way you’ll need: the monitor binary (or, for Docker, the published image), your server’s URL, and an enrollment token from Monitors → Add a monitor (see Adding your first monitor if you haven’t done this yet).