Custom metrics

WatchTower15 collects metrics for the things it has collectors for — your servers and your domains and services. Custom metrics are for everything else: the numbers that matter to your business and that no monitoring tool could know about on its own.

Applications created. Files uploaded. Orders placed. Queue depth. Pending tickets. Free licence seats. If you can measure it, you can send it here, chart it alongside the rest of your estate, and be told when it moves.

How it works

1. Create a metric source — a token your systems use to send.
2. Send a value over one HTTP request. No SDK, no agent, no signing.
3. The metric appears in Metrics, with its values charted in the Activity card on its page.
4. Attach alarms with your own thresholds and windows.
5. Optionally, show it on your servers, directly or by their tags, so it is charted beside each server’s CPU and memory.

curl -X POST https://api.watchtower15.com/api/metric-sources/ingest \
  -H "Authorization: Bearer wt15ms_…" \
  -H "Content-Type: application/json" \
  -d '{"points":[{"metric":"files.uploaded","value":1}]}'

That is the whole integration. A metric you have not declared is created the first time you send it.

The two kinds of metric

Every metric is a count or a level. The question that separates them is whether the values add up over time.

	Count	Level
Means	Something happened, and you want to know how many	A value you measure, and you want to know where it sits
Answers	“How many in the last hour?”	“What is it now, on average, at its peak?”
Examples	Applications created · Emails sent · Cars added	Users logged in · Pending tickets · Queue depth
You send	1 per occurrence, or a total for a period	The current value
Chart	Bars — occurrences per bucket	A line of the value over time
Alarms use	sum over a window	average, minimum, maximum, latest

The distinction matters because adding up a level is meaningless: the sum of “users logged in” over an hour is not a number anybody wants. Adding up a count is the question.

Not sure which?

Pick level. A metric created by sending to it is recorded as a level, and we do not guess from the values — a queue depth of 812 and a count of 812 look identical to us. You can change the type at any time, and nothing is lost when you do: your recorded values are re-read, never rewritten.

If you have used Prometheus or OpenTelemetry, count is a counter and level is a gauge.

Sending values

You can send one point per occurrence, or batch a period’s total into a single point. Both are correct, and for a count they give the same answer:

{ "points": [
    { "metric": "files.uploaded",  "value": 1,   "recorded_at": "2026-09-16T14:03:00Z" },
    { "metric": "files.uploaded",  "value": 1,   "recorded_at": "2026-09-16T14:03:07Z" },
    { "metric": "queue.depth",     "value": 812, "recorded_at": 1758031380 }
] }

Batching is the shape to build first. A source may send 60 requests a minute by default, so one request per business event runs out of room quickly — while one request carrying a count of 10,000 does not. See the ingest API for the full contract and every limit.

Zero is a useful value

Sending 0 to a count metric costs nothing and tells us the publisher is alive. Silence cannot distinguish “nothing happened” from “the job died” — a zero can.

What you get for each metric

• Three years of history. The Activity chart offers the last 1h, 3h, 12h, 1d or 5d, the last day by default, and reaches back the full three years through Custom: a length of your own, such as the last 2 weeks, or a range on its calendar.
• Your own alarms, as many per metric as you like, on your own thresholds — a floor and a ceiling on the same number, an early warning and a page.
• Incidents and notifications through the channels and policies you already use.
• Tags, so metrics group and filter alongside the rest of your estate. A metric’s tags can also come from its source: passed down, or copied when the metric is created.
• Charts on your servers’ pages, when you show the metric on servers.
• An Audit tab on its page — its creation, approval, edits, alarm changes, incidents, and when its first data arrived.

First data received is recorded for the first recent point a metric receives — backfilled history does not count — and again after Delete stored data.

Showing a metric on your servers

A metric about an application belongs next to the servers that run it. Link a metric to servers and it is charted on each one’s page, on the same time range as the server’s own charts, so a spike in Proposals created lines up with the CPU it cost.

Set it on the metric’s Create or Edit page, in the Show on servers card:

Field	Shows the metric on
Servers	Each server you pick
Servers tagged with all of	Every server carrying all of these tags
Servers tagged with any of	Every server carrying at least one of these tags

The two tag lists work together: a server must carry every tag of the first list and at least one of the second. A list left empty adds no condition. So all of production with any of GCC-API Backend, GCC Frontend reaches the production servers of either application, and not their staging servers.

Link a whole source instead from the metric source’s Edit page, in Show this source’s metrics on servers: every metric the source owns is then shown on those servers. A metric’s own links and its source’s add up — it shows on a server reached either way, once.

Where the charts appear. A server that shows at least one metric gets a Custom metrics tab, grouped by source. Each chart says why it is there — Direct, Tags or Source — and hovering the label gives the rule. The first eight also appear in a Custom metrics card on the server’s Overview, under Telemetry.

A few rules hold throughout:

• Only metrics that are switched on and approved are shown. One awaiting approval, or switched off, keeps its links and shows nowhere until it is on again.
• Seeing the charts takes both permissions: view servers and view custom metrics. Without view servers, a metric’s page counts the servers it is shown on rather than naming them.
• Nothing about the server changes. A linked metric’s alarms stay on the metric; it does not enter the server’s health, its alarm counts or its Audit tab.
• Changes are recorded on the metric’s or the source’s Audit tab.

Deleting a tag

Deleting a tag removes it from every metric’s and source’s tag lists. An all of list then asks for fewer tags, so the metric can show on more servers than before; a list left empty adds no condition. Each metric’s or source’s Audit tab records the change.

What it costs

£3 per metric per month, billed by the hour, in your organisation’s currency. A metric is charged for existing — not for how often you send to it — so a metric you write to once a day costs the same as one you write to every minute, and a quiet dead-man’s-switch metric is not cheaper to ignore.

Because it is billed hourly, a metric created halfway through a month pays for the hours it existed, and a 31-day month costs slightly more than a 28-day one.

There is no charge per datapoint and no overage: a hard limit on the metrics per organisation applies instead — 5 by default. The Account Limits card on Organisation → Settings shows yours, with your usage against it. Contact us to raise it.

Switching a metric off

A metric switched off is not charged for and stops accepting new values. Its recorded history is kept for 90 days from the day you switch it off, and then deleted — we warn you by email first. Switch it back on before then and nothing is lost.

Deleting a metric deletes its recorded values immediately.

Keeping your data safe

Your metric values are stored on a dedicated, encrypted instance, backed up daily. Our recovery point objective is 24 hours — in the worst case, a failure could cost up to a day of recorded values.

That is worth knowing before you wire a business-critical number to us: WatchTower15 is where you watch these values and alarm on them, not where they should exclusively live. Your own systems remain the system of record.

Limits at a glance

Metrics per organisation	5 by default (the Account Limits card shows yours)
Requests per minute, per source	60
Recent points (newer than 30 days), per metric	100,000 per rolling 24h
Backfilled points (older than 30 days), per metric	2,000,000 per rolling 24h
How far back you can send	3 years
How long values are kept	3 years
How far back an alarm can look	30 days

You can send history as far back as we keep it, so you can import what you already have rather than starting from the day you signed up. Points older than 30 days draw on a separate, much larger allowance, because no alarm can look back that far — they cost storage and nothing else. Backfilling needs an Idempotency-Key; see Sending metrics.

Charting and alarming are deliberately different: you can chart three years and alarm on the last month. An alarm re-reading three years of history every minute would cost far more than it is worth.

Every limit is raisable — ask us.