Introduction 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.

API reference

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

API reference#

The JSON API a monitor agent uses to enroll with a tenpm uptime server, sync its assigned check set, and report results and status back. Generated from docs-site/assets/tenpmuptime-monitor.yaml — see that file’s header for how it’s kept in sync with the code.

Download the raw OpenAPI spec (tenpmuptime-monitor.yaml)

The JSON API a monitor agent uses to enroll with a tenpm uptime server, sync its assigned check set, and report results and status back. This is the wire contract described in internal/model and implemented by internal/server/api_handlers.go; both binaries build against the same Go structs today, so treat this document as generated-by-hand from that code, not the other way around — if the two disagree, the code is right and this file is stale. Every route except POST /api/enroll requires the monitor's own API key, minted at enrollment. POST /api/enroll requires an enrollment token instead (an org token or a platform token — see the security scheme below), since no monitor exists yet at that point. Error responses across every endpoint are a plain-text body (one line) with a non-2xx status, not a JSON envelope — the handlers use Go's http.Error. The 4xx/5xx responses below document status code and body meaning; there is no shared error schema.

Creating an account

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

Creating an account#

Tenpm Uptime accounts are self-serve: you sign up with just an email address, and nothing is created until you confirm you own it.

Go to the login page and choose Create an account.
Enter your email address and submit.

You’ll see the same confirmation either way, whether or not that address already has an account — this is deliberate, so the page can’t be used to check who else is a Tenpm Uptime customer.

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:

Adding your first monitor

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

Adding your first monitor#

A monitor is the small agent that actually runs your checks. It’s a standalone, open-source binary that you run on your own infrastructure — a home server, a VPS, a container, wherever you’d like your checks to run from. The Tenpm Uptime server never runs your checks itself; it just hands the monitor a list of what to check and collects the results back.

Because the monitor runs on hardware you control, it can reach targets the public internet can’t — internal admin pages, LAN devices, anything behind a firewall.

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.

Creating your first check

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

Creating your first check#

A check is the thing you want watched — a URL, a TCP port, a TLS endpoint — and the rule that decides whether it’s healthy. Your monitors run it on the schedule you set and report the result back.

1. Open the check form#

Go to Checks and choose Add a check.

2. Describe the target#

Name — how it shows up on your Dashboard.
URL / target, prefixed with a scheme that tells Tenpm Uptime how to reach it:
- http:// or https:// — a web endpoint. This is the common case.
- tcp://host:port — a raw TCP connection, with an optional banner to match against.
- tls://host:port — a bare TLS handshake, for services that expect TLS as the very first bytes on the wire (an SMTPS or IMAPS port, for example), where an https:// check would fail and a tcp:// check would just time out waiting for a plaintext banner.
Check interval — how often it should run.

Every scheme also supports pass/fail rules beyond “did it connect” — matching response content, requiring a specific status code, and more. Start simple here; those options are covered in a dedicated guide once you’re ready for them.

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.

Reading the dashboard

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

Reading the dashboard#

The Dashboard is a grid: your checks down the side, your monitors across the top, and each cell showing whether that check passed the last time that monitor ran it. It refreshes on its own every 30 seconds.

Layouts#

Use the view switcher at the top of the page to change how monitors are grouped:

Collapsed (the default) — every monitor merged into a single column per check, so you see an up/down count rather than a wall of cells. Good for a quick glance across a lot of checks.
Grid — one column per monitor, so you can see exactly which monitor is reporting a failure.
By class — splits your own monitors from the shared fleet into two groups, useful once you’re using both.

Your choice is remembered in the page’s own link as you navigate, so paging or filtering won’t silently reset it back to the default.

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).

Introduction on Tenpm Uptime Docs

Shared vs. private monitors, and restricted checks

Shared vs. private monitors, and restricted checks#

Private monitors: yours, on your own terms#

API reference

API reference#

Creating an account

Creating an account#

1. Sign up#

Writing checks

Writing checks#

Schemes#

Response conditions#

Adding your first monitor

Adding your first monitor#

Notification channels

Notification channels#

Adding a channel#

Creating your first check

Creating your first check#

1. Open the check form#

2. Describe the target#

Managing monitors

Managing monitors#

Adding more monitors#

Organisation and account settings

Organisation and account settings#

Account settings#

Organisation settings#

Switching between organisations#

Reading the dashboard

Reading the dashboard#

Layouts#

Check history and charts

Check history and charts#

Time range#

Private-definition checks

Private-definition checks#

Running the monitor as a service

Running the monitor as a service#