PingMyThing for MSPs
Customer checks without another noisy RMM layer
Use PMT beside your RMM when a small number of customer-owned checks deserve a separate reporting lane. Deploy a transparent Windows starter check, or send a customer-owned result from a backup job, scheduled task, branch system, website check or external node.
Token → deploy or send → see
- Get a scoped project token.
- Deploy a BAT/PS1 starter check, or send GET/POST from the customer system.
- When a valid signal is received and shown, the station and signal view can be created.
- View selected customer signals in the PMT webapp on desktop, mobile or a NOC-style screen. Use API/CLI readback where another tool needs stored signal data.
Start with one customer, one system, and one useful signal.
Two ways to start
PMT should not require an MSP to model a whole estate before proving value. Start with a transparent check where it fits, or send a customer-owned signal where local logic matters.
Use starter checks
For Windows customer environments, starter checks can be deployed with BAT or PowerShell and pushed with Group Policy where suitable.
They are visible scheduled tasks, not opaque agents. They can be inspected, adapted, disabled, or removed.
Use customer-owned checks
A customer script, backup job, scheduled task, service check, external node, or application can decide the result locally.
PMT receives the chosen outcome and makes the received state visible.
Less noise by design
MSP tools often drift toward broader coverage: more endpoints, more metrics, more dashboards, then another layer to explain the noise.
PMT takes a narrower route. Use it for selected customer signals where the received result, or absence of an expected result, would change what you do.
Spear, not customer-estate net
A net catches everything across a customer estate and leaves someone to sort through it. PMT is closer to a spear: one chosen signal aimed at one customer condition that matters.
Chosen customer signals, not broad coverage
PMT does not discover the customer estate or collect everything.
Outcomes before explanation
The customer system, script, backup job, or check decides the result. PMT makes the received state visible.
Absence without false reassurance
If an expected customer signal stops arriving, that absence can be visible. PMT does not infer that everything else is healthy.
Before you consider rollout
PMT is deliberately limited. In MSP work, that limitation is part of the value.
PMT may fit if
- customer systems already know useful outcomes
- a small number of chosen signals is more useful than broad coverage
- you need visibility without adding another management plane
- non-reporting is a real operational risk
- customers will not accept another agent or remote-control layer
PMT may not fit if
- you expect automatic discovery or full estate visibility
- you want remote remediation, patching, or inventory
- you want PMT to diagnose faults or explain cause
- you need a compliance archive or system of record
- you want a replacement for your RMM or PSA
PMT reflects selected signals. It does not interpret them.
Useful first customer signals
The best MSP signals answer one operational question and point to the tool or process that already owns the work.
Backup completion
A backup check sends the result it can safely determine. PMT shows the received state; your backup console remains the place for investigation.
Scheduled jobs
A task or script reports completion, attention needed, failure, or unknown. If the expected report stops arriving, absence is visible.
External checks
A regional or external check can report whether a site, mail path, DNS result, or service condition was observed from outside.
Starter checks for Windows estates
Starter checks reduce time to value without turning PMT into an agent platform.
Where they fit, deploy a visible scheduled task for a specific customer condition. Where they do not fit, adapt the script or send your own signal.
Common starter checks can include heartbeat, disk space, reboot pending, and update failure conditions.
Transparent by design
- BAT/PS1 deployment path
- Group Policy rollout where suitable
- visible scheduled task on the endpoint
- inspectable and adaptable script
- removable without collateral damage
A starter check does not prove full system health. It reports the condition it was built to check.
Separate customers. Combine selected views.
MSP visibility often crosses ownership boundaries. PMT keeps customer signals separated at source, then lets selected views be brought together where access has been granted.
Project separation
Use customer, site, or branch projects to keep signals scoped and organised.
Scoped tokens
Share access at the project level without exposing the wider account.
Combined views
Selected read tokens can be used together in the webapp for a filtered operations view.
Mixed fleets and constrained sites
Signals can be sent from any customer source capable of making a simple HTTP request.
This allows the same signal model across Windows, Linux, macOS, hosted services, appliances, scripts, external checks, and branch systems without standardising the customer estate.
Useful where tooling is awkward
- branch offices and remote sites
- poor or variable connectivity
- partial trust relationships
- customer-owned systems
- mixed domains and workgroups
PMT observes selected outcomes. It does not need to manage the customer system.
When a signal needs attention
You do not investigate inside PMT.
You use the tools that already own the work: RMM, PSA, RDP, SSH, backup console, firewall panel, hosting panel, logs, or customer process.
PMT makes the received condition visible. Your existing tools and judgement decide what happens next.
What PMT does not do
- access customer systems
- run commands remotely
- apply patches or updates
- collect inventory or broad performance metrics
- diagnose causes
- replace your RMM or PSA
- act as a compliance archive
It reflects selected signals and whether they continue.
Useful next steps for MSPs
Start with the path that removes the most uncertainty without adding operational drag.
Use your own checks
Send customer-owned results from scripts, jobs, tools, or apps.
When the RMM is noisy or blind
PMT is not an RMM replacement. It is useful when a specific customer condition should report separately from broad estate tooling: backup result, scheduled job result, branch check-in, external reachability, mail-path check or temporary assessment signal.
RMM noise
Use PMT for selected customer checks that should not be buried in broad alert streams.
Customer separation
Keep customers, branches or sites in separate projects with scoped tokens.
Fast assessment
Deploy one visible check, inspect the result, then remove or adapt it.
No control-plane creep
PMT does not patch, inventory, remote into or manage the customer estate.
A customer signal view MSPs can actually use
Keep customers, branches or sites separated at source using projects and scoped tokens. Where access has been granted, selected read tokens can be viewed together in the webapp so an operations view can span the signals that matter without becoming a shared customer control plane.
One customer
Start with one useful customer signal.
Many customers
Keep customer projects separated at source.
Tiny outbound signals
A small GET or POST result is often enough where bandwidth, trust or installation rights are constrained.
Separated projects
Keep customers, branches, sites or use cases apart using project-scoped tokens.
Combined views
Bring selected read views together where access permits.
Mobile or NOC-style
Use the same webapp for quick checks or a focused operations screen.
Inspect before rollout
For MSP use, every check should be understandable before deployment.
- what the check represents
- what it does not prove
- where it can mislead
- how it can be adapted or removed
Get your signal
Start with one customer.
Deploy one starter check or send one customer signal.
Replace the test with something worth seeing.