FROM Our Founder
Why PMT exists
I built PingMyThing because I was tired of monitoring tools that demanded attention without earning it.
The useful check was often simple. The hard part was everything around it once the check had to work safely, repeatedly, and across real customers, sites and constraints.
PMT is not selling the ping. It is the disciplined operating layer around selected signals.
The real work
Anyone competent can build something that receives a small HTTP signal.
That was never the interesting part.
The real work starts when the signal needs to be separated, shared safely, protected, viewed on mobile, read back through an API, rolled out cleanly, and removed without leaving a mess.
Built from imperfect conditions
I have spent decades running systems in places where failure is normal and budget, bandwidth and trust boundaries matter.
Servers, email, websites, customer infrastructure, branch sites, NGOs, field systems and remote environments all have one thing in common: the perfect platform usually assumes conditions you do not actually have.
The questions were simple
- did the backup report
- did the scheduled job run
- is the site reachable
- did the branch server check in
- is the gateway, fridge, pump or sensor still reporting
- has something gone quiet that should not have gone quiet
A one-liner can often answer the question.
Spear, not net
In monitoring, excess creates noise. Noise creates fatigue. Fatigue leads to neglect. Somewhere inside that noise may be the one signal that actually needed attention.
The net catches everything indiscriminately until attention, trust and signal are exhausted.
The spear is different. It takes only what is necessary, with intent and precision.
PMT chooses the spear, not because it is elegant, but because it is more honest about how people actually work under pressure.
PMT makes selected remote signals visible, including silence where reporting was expected.
You choose what matters.
PMT gives it somewhere simple to report.
Why this was not just a weekend receiver
PMT had to be designed around more than data minimisation.
GDPR alignment from the ground up: small payloads, project separation, scoped tokens, revocation and rotation, expiry where appropriate, protected identifiers, encryption in transit and at rest, edge protection, and controlled behaviour when things fail.
Those choices do not make PMT risk-free or automatically compliant for every use case. They do mean the system was designed around constrained, deliberate signal handling rather than broad telemetry collection.
What the hard middle looked like
- token authentication
- scoped project access
- token rotation, revocation and TTL where appropriate
- deterministic encryption or protected identifiers where used
- encrypted transport
- storage-layer encryption
- Cloudflare edge protection
- retry and back-off behaviour
This is the part a quick prototype usually avoids.
Practical reasons PMT exists
These are the situations that kept recurring.
Client assessment
Use transparent checks to surface hard-to-reach signals, or to gather specific data that you need. Remove cleanly when done.
Cost-sensitive organisations
Start with the few conditions that actually change action, not a broad platform nobody can afford or maintain.
Resource-constrained sites
A tiny outbound signal can be more realistic than a full monitoring stack over poor, metered or unstable links.
Shared visibility
Scoped tokens and projects let the right person see a relevant signal view without gaining control of everything else.
Mobile-first operations
The useful signal is often needed when someone is away from the desk. A clear browser view on a phone matters.
Mixed systems
Windows, Linux, websites, branches, WordPress and field devices can all report through the same small signal model.
Start small
Send one signal. See whether the path works. Replace the test with something that matters.