How PingMyThing works

Source → PMT → view or use the result.

A script, application, job, device or other source produces a small result. PMT receives and preserves it. You see or use the result through the webapp, API or command line.

That is the basic model.

SOURCE
knows the answer
→
PMT
receives + preserves
→
WEBAPP / API / CLI
see or use the result

1. Decide what is worth knowing.

Start with one explicit question:

  • Did the backup succeed?
  • How much disk space is left?
  • Did this machine receive the required change?
  • What is the water level?

You decide what the result means and why it is worth collecting.

PMT does not discover that meaning for you.


2. Let the source produce the answer.

The source can be PowerShell, Bash, a scheduled task, cron, application code, WordPress, a backup script, a gateway, device or external checker.

Use a PMT starter check where one already fits, or send the result from your own logic.

PMT does not need to deploy or execute the check.

Starter checks →   Use your own checks →

3. Send a small result.

A simple GET can be enough:

https://ingress.pmtapi.net/v2/?tkn=YOUR_TOKEN&stn=SERVER-3&sens=backup_result&val=-1

PowerShell:

Invoke-RestMethod `
  "https://ingress.pmtapi.net/v2/?tkn=YOUR_TOKEN&stn=SERVER-3&sens=backup_result&val=-1"

Descriptive sens names are normally the simplest starting point.

Signal format and examples →

4. Look for accepted.

When PMT returns HTTP 200 with {"status":"accepted"}, the insert has been acknowledged under PMT's configured MongoDB write concern.

That is the successful storage contract. It does not imply exactly-once delivery, independently verified physical-disk persistence, downstream notification, human attention or absolute service availability.

5. See or use the result.

For most people, the webapp is the simplest view. The same authorised result can also be used elsewhere.

WEBAPP

See the selected result in the primary human-facing view.

See the PMT webapp →

API / CLI

Use authorised results through API, PowerShell, command line, CSV, Excel or another application.

API & CLI access →

6. What if nothing arrives?

Where a result is expected regularly, cadence and stale rules can make non-arrival visible.

This matters because a source can fail by simply going quiet.

Silence can be operational information.

A previous normal value and a source that should already have reported again are not the same condition.

A stale state means an expected result did not arrive within the active cadence. It does not diagnose why.

What PMT does not do.

PMT does not:

  • discover your estate
  • decide what should be monitored
  • deploy scripts
  • remotely control systems
  • diagnose root cause
  • infer whole-system health
  • reinterpret the result your source sent

The source remains responsible for the answer.

If a source sends the wrong answer, PMT can faithfully preserve the wrong answer.

PMT transports and presents selected operational facts. It does not manufacture truth that was not present at the source.

Start with one result.

Choose one useful question. Use a starter check or your own logic.

Send the result and see it appear.