Use Your Own Checks

Use your own checks. View the results centrally.

PMT accepts small GET or POST signals from scripts, jobs, applications, websites, devices and processes.

Your system decides the result locally. PMT receives the selected outcome and makes the received state available in the browser view or through the read API.

No agents. No remote commands. No inventory layer.

Get your signal

Sender owns the meaning

PMT does not run the check for you.

1. Decide locally
A script, job, app, device or person defines the condition.

2. Send one result
Use a short, stable signal name and a selected value.

3. View centrally
PMT shows received states and can make expected silence visible in the webapp.

Before you write or connect a check

PMT works best when the source already knows the answer you care about.

PMT may fit if

you already have scripts, jobs, apps or devices that can decide useful outcomes
one selected result is more useful than broad telemetry
you need a central view without giving PMT control of the source
a missing expected signal would change what someone does

PMT may not fit if

you need PMT to discover systems or inspect endpoints remotely
you want PMT to diagnose the cause
you need broad performance metrics or logs
you need guaranteed delivery, compliance archiving or a system of record

PMT reflects selected signals. It does not interpret the world.

What your check sends

A custom signal should be small and stable.

tkn — send token identifying where the signal belongs
stn — station, system, site, device or source name
sens — short signal/check name
val — selected state or scalar value
tag — optional short grouping label

For public examples, treat sens as a short string such as backup_result, site_reach or pump_state.

Keep names boring

Good signal names are short, stable and easy to reason about.

Good
backup_result, disk_state, site_reach

Risky
names that embed secrets, customer-sensitive detail, long descriptions or changing meaning

Rule
if the signal needs a paragraph to explain it, tighten the check.

Send by GET or POST

Use whichever path fits the sending environment. The important point is that the source decides the result before sending it.

POST JSON

Useful when your script can send structured data.

curl -sS -X POST https://ingress.pmtapi.net/v2/ \
  -H "Content-Type: application/json" \
  -d '{"tkn":"'"$PMT_SEND_TOKEN"'","stn":"server-01","sens":"backup_result","val":-1}'

Keep tokens in environment variables or secrets where possible.

GET query

Useful for simple scripts, constrained clients or quick tests.

curl -sS "https://ingress.pmtapi.net/v2/?tkn=$PMT_SEND_TOKEN&stn=server-01&sens=backup_result&val=-1"

Use GET only where query-string exposure is acceptable for your environment.

Useful custom checks

Start with signals that would change what someone does. Avoid collecting data just because it is available.

Backup completion

A backup script sends -1 when it completes and -3 when its own check reports failure.

PMT does not verify restore quality.

Scheduled job

A scheduled task or cron job sends -1 after it runs.

If it stops reporting, the webapp/operator view can make the missing expected signal visible.

Website reachability

An external or local check sends -1 when reachable and -3 when unreachable.

PMT does not diagnose DNS, hosting or application cause.

Scalar condition

A source sends a value such as free GB, latency, temperature, voltage or water level.

Use scalar values where a threshold or range changes action.

Application health

An application decides whether a selected internal condition is OK, needs attention, or unknown.

Meaning stays in the app or check.

Remote device

A branch device, gateway or field process sends a small selected state or reading.

Do not imply PMT discovers or controls the device.

What PMT does with your signal

PMT accepts submitted readings for processing, stores telemetry where processing succeeds, and makes stored values available for browser display or API readback.

The webapp can apply configured display rules, colour ranges and expected reporting patterns.

Those display rules shape how a received value or missing expected signal is shown. They do not change what your signal means.

What PMT does not do

run your custom check remotely
inspect the source system
collect inventory or broad logs
decide root cause
guarantee every submission is stored or displayed
act as a compliance archive or sole source of truth

Use retry or confirmation logic in your own sender where the use case requires it.

Read results back

PMT is not only a browser view. Stored signal data can be queried through the read API and used in your own tools, scripts, reports or operational screens.

Use this when you want PMT as a small signal layer feeding another process.

API and CLI access