Use your own checks
If your script, application, job, website, gateway or device can produce the answer, it can send that selected result to PMT.
PMT does not need to reproduce the source logic. The source decides what the result means.
PMT gives the answer a consistent receiving and read path. A successful {"status":"accepted"} response means the insert has been acknowledged under PMT's configured MongoDB write concern.
Typical sources
PowerShell · Bash · scheduled tasks · cron · backup scripts · application code · WordPress · customer software · gateways · devices · external checkers
Requirement: the source can produce the selected result, hold an appropriate ingress credential and make an outbound HTTP request.
A result can be small.
PowerShell:
Invoke-RestMethod ` "https://ingress.pmtapi.net/v2/?tkn=YOUR_SEND_TOKEN&stn=SERVER-3&sens=backup_result&val=-1"
Bash / curl:
curl -fsS "https://ingress.pmtapi.net/v2/?tkn=YOUR_SEND_TOKEN&stn=branch-a&sens=check_in&val=-1"
JSON POST works too.
{
"tkn": "YOUR_SEND_TOKEN",
"stn": "STORE-17",
"sens": "last_sync_age_min",
"val": 14
}
Descriptive sens names are normally the simplest starting point. Numeric compatibility input is normalized to string. val must be finite numeric data.
Keep the meaning local.
Suppose an application already knows whether its last sync completed successfully.
The application can decide:
sync_status = -1
means its configured normal result.
PMT does not need to understand the application database, sync protocol, customer workflow or reason for failure.
That stays with the system that actually knows the condition.
Deployment is separate.
PMT does not have to deploy your check.
Use the mechanism that already fits:
- Group Policy
- Intune
- RMM
- scheduled tasks
- cron
- application deployment
- firmware
- local configuration management
PMT receives the result.
The same result path supports WATCH, ASK and MEASURE.
They are different operational uses of the same small send model.
WATCH
A backup script reports its final outcome after each run.
Where a result is expected regularly, the webapp can also make missing expected reporting visible.
Watch the outcome, not merely whether a scheduler started.
ASK
A temporary PowerShell check asks: How much free disk space is available across these machines?
stn = stable machine identity sens = free_disk_gb val = measured free GB
PMT collects the answers. It does not automatically know which machines were expected to answer.
MEASURE
A device or script can report:
stn = pump-4 sens = pump_temperature val = 32.4
The webapp can display the number or map it to configured ranges. The raw result remains numeric.
Name checks for the question they answer.
Good descriptive sens examples:
backup_result free_disk_gb last_sync_age_min required_update_present pump_temperature
A descriptive identity can become useful immediately without predefining a global sensor directory.
Use numeric/opaque identities only where the mapping step has a real benefit.
Do not overstate the result.
A source check can be wrong.
PMT preserves what it was sent.
A green presentation means only that the selected result currently maps to the configured normal state.
Use narrow credentials
Use a send-scoped token for senders where practical.
Keep reusable credentials out of public examples and committed code.