For software & POS providers
Know how your software is doing out there.
Your software may be running on hundreds of customer-owned PCs, terminals or local servers.
You support the application, but you do not necessarily manage the whole machine, network or site.
So when disk space disappears, a service stops, a sync fails or something local prevents your software doing its job, you may not know until the customer calls.
PingMyThing gives the few conditions that affect your software a direct path back to you.
Why the support call starts late
The customer notices first
The problem has already affected somebody before support sees it.
The application depends on local conditions
Disk, services, database reachability or sync can fail outside your software itself.
You do not own the whole endpoint
You need selected application visibility without becoming the customer's MSP.
The customer should not have to be your monitoring system.
A typical support call starts after the problem has already affected somebody:
- the POS stopped syncing
- reports are not arriving
- an overnight process failed
- the application cannot reach its database
- something that worked yesterday no longer works today
Your technician then has to work backwards.
Sometimes the answer could have been visible before the call.
Monitor the installation, not everything around it
A software provider usually does not need full endpoint inventory, every Windows event, patch-management control or another remote-management platform.
You need the small number of conditions that materially affect your application:
- application service state
- database reachability
- last successful sync
- backup outcome
- free disk space
- expected upload completed
- installation check-in
- required dependency available
Let your software report what it knows.
The best place to decide whether your application is working is often the application itself.
Your software, service or local check can evaluate the condition and send PMT a small result.
PMT does not need to understand your database, business logic or application architecture. Your software decides what the result means. PMT gives it somewhere consistent to land.
Application state
Is the software doing the thing it is responsible for?
Service running, database reachable, required dependency available, application check-in present.
Data & process outcome
Did the useful work actually happen?
Last successful sync, upload, export, backup or scheduled process result.
Selected local context
Is a simple machine condition about to affect the application?
Free disk space, selected update state, version, connectivity or another narrow operational fact.
One view across customer installations.
Instead of waiting for individual support calls, see selected installation state across the customer base.
- Store A — normal
- Store B — sync requires attention
- Store C — one terminal stopped reporting
- Store D — disk space becoming low
The view can be useful to your support team, an operations manager or a customer without exposing development or remote-management systems.
You do not have to become the customer's MSP
Monitoring a few application-relevant conditions does not mean taking responsibility for managing the customer's whole PC.
If the customer needs full endpoint management, they should have an MSP or appropriate management platform.
PMT lets the software provider stay focused on the part of the environment that affects its own service.
When PMT is probably not the answer
If you already manage every customer endpoint through an RMM and it reliably gives your support team exactly the application-specific information they need, there may be little reason to add PMT.
Likewise, use specialist tools if you need full application performance monitoring, traces, crash analytics or endpoint remediation.
PMT fits when the requirement is smaller: a few explicit customer-installation results that should be visible before somebody has to report the problem manually.
Start with the support issue you see most often.
Disk space. Last successful sync. Application service state. Database reachability. Backup outcome.
Send one result from one customer installation and decide whether seeing it earlier would have changed anything.