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.

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.

Monitor API reference

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

Monitor 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 agent/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 /monitor-api/v1/enroll requires the monitor's own API key, minted at enrollment. POST /monitor-api/v1/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. Every route here is rate-limited per client address (about 10 requests a second with a burst of 30) and answers 429 rate limit exceeded beyond that. A monitor that syncs and reports every 45 seconds is nowhere near it. Versioning (2026-09-22, path moved again 2026-09-27): every path below moved under /api/v1/ in the first pass, then to /monitor-api/v1/ in a second, unrelated to versioning itself - a new, separate customer-facing account API (/account-api/v1/..., not documented in this file) needed a path of its own and collided with this one's /api/v1/checks and /api/v1/status, so the monitor API got a distinct prefix instead of a third segment under a shared one. The rule from here on: a JSON change within v1 is additive only - a removed field or a changed meaning gets a new /monitor-api/v2/ path instead of changing what v1 means. Neither the fully unversioned form (/api/..., no version segment at all) nor /api/v1/... itself exists any more - both were renamed with no permanent alias, since every monitor deployed at each point in time was ours to redeploy. The /api/v1/... → /monitor-api/v1/... move was briefly served from both prefixes during the fleet's own migration window; that temporary routing was removed once every deployed monitor (this project's own fleet, and any private monitor a customer runs) was confirmed redeployed on a build calling the new path. Treating a prefix rename as a standing policy a third time should not be expected: the next breaking change bumps the version segment (/monitor-api/v2/...), not the prefix.

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.

Account API reference

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

Account API reference#

The read-only, customer-facing JSON API for a person’s own account data — checks, monitors, results, heartbeats, notification channels, members, and plan settings — plus a full data-export endpoint. This is a different surface from the monitor API: that one is what a monitor agent uses to talk to the server, authenticated as a monitor; this one is what a person (or a script acting on their behalf) uses to read their own org’s data, authenticated with their own bearer token minted from the organisation settings page. Generated from docs-site/assets/tenpmuptime-account.yaml — see that file’s header for how it’s kept in sync with the code.

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.

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.

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. Your plan sets the shortest interval you can choose (see Plans and billing).

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

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.

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

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#

Creating an account

Creating an account#

1. Sign up#

Monitor API reference

Monitor API reference#

Writing checks

Writing checks#

Heartbeat checks

Heartbeat checks#

Account API reference

Account API reference#

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#

Reading the dashboard

Reading the dashboard#

Layouts#

Members and invitations

Members and invitations#

Public status page

Public status page#

Plans and billing

Plans and billing#

What each plan includes#

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#