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.

Schemes#

The prefix on your target URL picks the checker:

Scheme	What it does
`http://` / `https://`	Fetches the page. Supports all the response conditions below.
`tcp://host:port`	Opens a raw TCP connection, optionally checking for a banner.
`tls://host:port`	Performs a bare TLS handshake with nothing else on top — for a service that expects TLS as the very first bytes on the wire (SMTPS, IMAPS), where `https://` won’t speak the right protocol and `tcp://` will just time out waiting for a plaintext banner it’s never going to get.

Response conditions#

These decide whether an otherwise-successful connection still counts as a failure:

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.

Give each channel a name (how it’ll show up when picking channels elsewhere) and its destination — the ntfy topic, email address, or webhook/Slack URL. A channel’s kind is fixed once created; if you need to change one kind to another, add a new one and delete the old one.

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.

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.
Change password — requires your current password. Changing it signs out every other browser or device logged into this account; the one you used to make the change stays signed in. If you ever suspect your account is compromised, changing your password is the fastest way to kick out anyone else’s session.

Organisation settings#

Organisation name — shown in the navigation bar and throughout the dashboard. Any member can rename it.
Shared monitor fleet and Notification channels — covered in Managing monitors and Notification channels respectively.

Switching between organisations#

If your account belongs to more than one organisation, a dropdown appears in the navigation bar to switch which one you’re currently viewing — every page (Dashboard, Checks, Monitors) shows that organisation’s data only. Switching just changes which org your session is pointed at; it doesn’t affect anyone else.

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 a way to build/pull it), 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).