Metric sources

A metric source is a credential: a bearer token one of your systems uses to send custom metrics. It also owns the metrics it sends, and that ownership decides what its token can reach.

Creating one

Metrics ▸ Metric sources ▸ Add. Give it a name that says which system will use it — billing-worker, ci-runner, checkout-lambda — and save.

The token is shown once, immediately after creation. We store only a hash of it, so if you lose it nobody can recover it and you will need to issue a new one.

Authorization: Bearer wt15ms_…

A source owns its metrics

A metric belongs to exactly one source, and only that source’s token can send to it.

Metric keys are unique per source, not per organisation. Two sources can each have a purchase_orders.created; they are separate metrics, with separate history, billed separately.
A fleet shares one token. Twenty workers holding the same source’s token all write to one files.uploaded, and you get one metric with one history. Give them a token each and you get twenty metrics, each charged separately.

See which metrics a token can reach.

Rotating and revoking

Action	What happens
Rotate	A new token is issued and shown once. The old one stops working immediately — there is no overlap, so redeploy your publisher with the new value.
Revoke	The token stops working and no new one is issued. Use this if a token has leaked.
Pause (switch the source off)	Sends using this token are refused, and it can be switched back on.

None of these touch the metrics the source created. They keep their history, keep charting and keep being charged for — because they are still metrics you are monitoring. To stop being charged for a metric, switch off (or delete) the metric, on its own page.

Showing its metrics on servers

From the source’s Edit page, Show this source’s metrics on servers charts every metric the source owns on the servers you choose: picked one by one, or by their tags (all of one list and any of the other). It works exactly as a single metric’s links do, and the two add up. See Showing a metric on your servers.

The source’s page then shows how many of its metrics are shown, and on how many servers. A metric that is switched off, or awaiting approval, is not counted and not shown.

Tagging a source

A source carries tags of its own, from the same groups a metric’s come from: the Custom Metric group, any other group scoped to custom metrics, and the organisation-wide groups, your own groups among them. Server, domain, service, log source and database tags cannot be put on a source. See Tagging.

Pick them in the Tags card on the source’s New or Edit page, under the form. The source’s page shows them in its Tags card, on the Overview tab. The Metric sources list has a Tags column and a Tags filter, which lists only the sources carrying every tag you pick.

These are the source’s own tags. The tag lists of Show this source’s metrics on servers are something else: they pick servers.

Passing a tag change down to its metrics

When you Save a source whose tags you changed, WatchTower15 first works out what the change would do to the metrics the source owns. If it would change at least one, it asks you, in Apply tag changes to this source’s metrics?:

Added to the source: each tag you added, with how many metrics it would be added to and how many already have it.
Removed from the source: each tag you removed, with how many metrics it would be removed from and how many don’t have it.
How many metrics change, and which: the first 25 by name, each with the tags it gains (+) and loses (−), then and N more.

Then pick one:

Button	What it does
Save and apply to N metrics	Saves the source, and makes the same change on its metrics. It confirms Metric source updated. Tags applied to N metrics.
Save source only	Saves the source with its new tags, and leaves every metric’s tags as they were.
Back	Saves nothing. The form keeps your edit, so you can change it or save again.

There is no question, and the source is saved at once, when you did not change its tags, when it owns no metrics, or when every metric already reflects the change.

Every metric the source owns counts, including those awaiting approval and those switched off, so a metric approved later carries the change too. Another source’s metrics are never touched.

Only what you changed passes down

Applying adds to the metrics the tags you added in this edit, and removes from them the tags you removed in it. No other tag changes on any metric:

a tag a metric has of its own, which the source never had, stays;
a tag the source keeps, but a metric does not have, is not added.

For example, a source’s tags go from A, B to B, C: C is added, A is removed and B is kept. X is a tag one of its metrics carries of its own.

Metric	Before	After Save and apply	Why
m1	A, X	X, C	A was removed and C added; X is the metric’s own tag, and is untouched
m2	B	B, C	C was added; B is untouched
m3	A, C	C	A was removed; it already had C, so C is not added again
m4	X	X, C	C was added; B is not added, because this edit did not add B

With Save source only, the source’s tags become B, C and m1 to m4 keep their Before tags.

Tags are copied, not inherited

Applying copies the change onto each metric, once. After that a metric’s tags are its own: remove one on the metric and it stays removed. A later change to the source’s tags reaches its metrics only when you apply that change too.

As everywhere in WatchTower15, the last save wins: if a metric’s Edit page was open while you applied, saving it puts back the tags that page loaded.

If someone else changed the tags

If the source’s tags were changed by someone else after you opened its Edit page, your Save is refused and nothing is saved. The Tags card reads This source’s tags were changed by someone else since you opened it. Reload the page and try again. This is checked before the question opens, and again when you press either save button.

A Save that does not change the tags keeps whatever tags the source has by then, so changing only its name or description never undoes someone else’s tag change.

If the change cannot be previewed, nothing is saved and We could not preview the tag changes. Nothing was saved. is shown. If one of the question’s save buttons fails for any other reason, the question closes, the form keeps your edit, and The metric source could not be saved. Reload the page to see its current tags. is shown.

New metrics start with their source’s tags

A metric created by sending a new key starts with its source’s tags as they are at that moment, whether it is created awaiting approval or recording. If the source is being saved at that very moment, the key is counted metric_create_busy and the next push creates it.
On New Metric, picking a source fills the Tags card with that source’s tags. Remove any you don’t want before Create. Once you have edited the card yourself, picking another source leaves it as you made it.

Either way these are the metric’s own tags from then on, as after an apply.

On the Audit tab

The source’s Audit tab records its own tag changes, as added and removed. When you apply, each metric whose tags changed records the change on its own Audit tab, with Via metric source: and the source’s name, and the source’s event adds Applied to metrics: and how many changed.

Deleting a source

Deleting a source deletes every metric it owns, with their recorded history and their alarms, in one step that cannot be undone. The confirmation says so before anything is removed.

Rate limits

Each source may send 60 requests per minute, unless WatchTower15 has set a different limit for your organisation or source. That is a limit on requests, not on values: one request can carry many points, and a single point can carry a count of 10,000.

If you are hitting it, batch before asking for more — it is almost always the right fix, and it is cheaper for both of us. If batching genuinely will not do it, ask and we will raise the limit for your source.

See the ingest API for the full request contract.