PingMyThing
See selected check results without another agent
Deploy a transparent starter check, or send a small result from a script, scheduled task, backup job, website, application, device, gateway or sensor. PingMyThing (PMT) shows the received state in a browser, mobile or NOC-style webapp.
Each reported result becomes a small PMT signal. The source decides what the result means. PMT receives, stores and displays it.
No endpoint agent. No inventory collection. No remote access. No control plane.
Check → result → webapp
- Get a scoped token
- Deploy a starter check or send a small result
- PMT receives the result as a signal
- View the received state in the webapp
Start with one selected check where the result is clear and someone would act if it changed - or stopped reporting when expected.
Start with a ready check or use your own
PMT does not require every user to begin by writing code. Start with a transparent starter check where it fits, or report the outcome of logic you already control.
Start with a transparent starter check
Deploy a small, visible check for a useful Windows condition. Each starter check uses ordinary scripts and scheduled tasks that can be inspected, changed, disabled or removed.
- BAT/PS1 deployment
- Group Policy rollout where appropriate
- Heartbeat, disk, reboot and update conditions
Use your own checks
Use an existing PowerShell or Bash script, cron job, backup process, application, website, gateway or device. Your source decides what the result means and sends only the small outcome PMT needs to display.
- PowerShell, Bash, cron and scheduled tasks
- Backup jobs, websites, devices and services
- GET or POST from anything that can send HTTP
Visibility without taking control
PMT receives selected check results. It does not discover the estate, diagnose the cause, manage the machine or decide what a local result means.
Start without modelling the estate
Create the project and begin sending useful results. PMT does not need to discover, inventory or reproduce the system being checked.
No endpoint agent
Starter checks are visible scripts and scheduled tasks. Custom checks stay under your control.
Small outbound results
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
Where access is granted, selected projects can be viewed and filtered together in the webapp.
Webapp first,
API when needed
Use the webapp on desktop, mobile or a compact NOC-style screen. Read stored results through the API or CLI when another tool needs them.
Less noise by design
Many tools try to see more, collect more, abstract more, and then add another layer to explain the noise.
PMT takes the opposite route. It is for selected signals that someone has chosen to send because the result would change what they do.
Spear, not net
A net catches everything and leaves someone to sort through it. PMT is closer to a spear: one chosen signal aimed at one condition that matters.
Chosen signals, not broad coverage
PMT does not discover systems or collect everything.
Outcomes before explanation
The source decides the result. PMT makes the received state visible.
Absence without reassurance
If an expected signal stops arriving, that absence can be visible. PMT does not infer that everything else is healthy.
Before you add signals
PMT works best when the question is clear and the result would change what someone does.
PMT may fit if
- you want visibility without another control layer
- a starter check answers a useful first question
- your own script, job or device already knows the result
- non-reporting is a real operational risk
- mixed systems need one simple reporting pattern
- branches or remote sites have limited connectivity
PMT may not fit if
- you expect automatic discovery or full visibility
- you want remote remediation, patching or inventory
- you want diagnosis or root cause analysis
- you need a compliance archive or system of record
- you need safety-critical or life-critical control
PMT reflects selected signals. It does not interpret them.
From first signal to ongoing visibility
The first signal proves the path. Repeated signals create useful rhythm.
A scheduled starter check, script, job or device reports its chosen result. If expected signals stop arriving, absence becomes visible too.
Use the browser webapp for day-to-day visibility, mobile checks or a lightweight operations screen. Use API/CLI access when you want the same signal data in your own tools.
Simple operating model
- source determines meaning
- PMT accepts the small result
- webapp shows received state
- cadence makes silence visible
- API/CLI lets you consume data elsewhere
Useful first checks
Begin with one result that is clear, limited and worth acting on if it changes—or stops arriving when expected.
Windows starter check
Heartbeat, disk space, reboot pending or update failure from a visible scheduled task.
Backup result
A backup job reports OK, act soon, act now or unknown after it evaluates the result.
Websites and WordPress
Show selected results for site reachability, backup status, SSL expectations, DNS state or an email-path check.
Branch and remote sites
Receive a small outbound check-in from a branch, gateway or remote machine over constrained or unreliable links.
Customer machines and POS systems
Show selected service, disk, update, version or sync-job results from customer-owned PCs without remote control.
Your own checks
Send a small result from PowerShell, Bash, an application, job, device or existing operational tool.
Common starting points
The same small result model can support MSPs, administrators, web agents and software providers. It can also serve selected equipment, field and research uses where meaning is already known at the source.
MSPs
Deploy starter checks or customer-owned signals without adding another control plane.
Admins
Use predefined checks or your own scripts to make selected system conditions visible.
Web agents
Use selected WordPress, site, backup, SSL, DNS or email-path signals without a heavy management stack.
Beyond conventional IT
Selected equipment, field and sensor checks
PMT can also receive small results from equipment, gateways, field sensors and remote processes where the meaning is already known at the source.
Useful examples
- remote equipment or gateway check-in
- environmental sensor data arrival
- battery, power or threshold state
- water level or temperature condition
- field process completion
PMT makes the submitted result and configured stale state visible. It does not become an IoT platform, scientific analysis system or metadata store.
Start with one result worth seeing
Choose a transparent starter check or report an outcome from something you already run.
Confirm that the result appears in the webapp before expanding the scope.