PingMyThing for Web Agents
Client site signals without a heavy site-management platform
Use a WordPress plugin, hosting-side script, external check or custom signal to report selected client-site outcomes: backup result, SSL window, DNS expectation, uptime/reachability, email path or plugin-aware condition. PMT makes received states visible without taking over content, hosting or server management.
Token → plugin, check, or send → see
- Use a scoped project token
- Use the WordPress plugin, a starter check, or your own GET/POST signal
- When a valid signal is received and shown, the station and signal become visible
- View selected client signals in the browser, mobile view, NOC-style screen or API
Start with one client site and one useful signal.
Three practical ways to start
Use the lowest-friction route that answers a real client-site question. The source still owns the meaning; PMT makes the received result visible.
Use the WordPress plugin
Use the PMT plugin where it fits: site-side checks, site-care signals, backup results or plugin-aware conditions. Keep the signal small and explicit.
Use external checks
Use outside-in checks for site reachability, SSL windows, DNS expectations or email-path tests. External signals can sit beside internal site or server signals.
Use your own checks
Use hosting scripts, cron jobs, backup scripts, deployment jobs, APIs or one-line commands. Local logic decides the result before PMT receives it.
Before you add another site to anything
PMT is deliberately limited. That is part of the value for web agents managing many small client risks.
PMT may fit if
- one chosen site, backup, DNS, SSL or email-path signal would change what you do
- a WordPress plugin, hosting job, external check or script can decide the result
- you want visibility without another site-management platform
- non-reporting from a site or check is a real operational risk
PMT may not fit if
- you expect automatic discovery or full site visibility
- you want PMT to manage content, hosting, SEO or performance
- you want diagnosis, root cause or performance tuning
- you need a compliance archive or system of record
PMT reflects selected signals. It does not interpret them.
Useful first signals for client sites
Start with signals that answer a clear operational question. Do not add checks just because they are easy to add.
WordPress condition
Did the plugin or site-side check report a condition that needs attention?
Backup result
Did the site or hosting backup job report the outcome you expected?
SSL window
Is the certificate inside the range you consider acceptable?
DNS expectation
Did the DNS check return the expected result?
External reachability
Did an outside check report that the site responded as expected?
Email path
Did the message complete the route from send to receive?
Useful client-site signals
WordPress backup result
SSL expiry window
DNS expectation
External reachability
Email path
Hosting-side script
WordPress plugin path
The WordPress plugin gives web agents a direct route for selected site-side signals where plugin access is appropriate.
Use it where it reduces friction. Use external checks, hosting scripts or server jobs where those are cleaner or safer.
The plugin should not turn PMT into a site-management platform. It should send selected outcomes that matter.
Internal and external signals together
A useful project can combine different signal sources without making them the same thing.
- WordPress plugin signal
- hosting-side script or cron job
- external reachability check
- SSL or DNS check
- backup result
- end-to-end email-path result
PMT shows selected received states. Your tools decide what happens next.
Separate clients, combine selected views
Use client-specific projects and scoped tokens to keep site signals separated at source. Where access has been granted, selected read tokens can be combined in the webapp for a practical operational view.
Client projects
Keep each client, site group or hosting context in a separated project when that matches responsibility.
Scoped tokens
Share only the project access needed. Avoid exposing unrelated clients or account-level access.
Mixed hosting
Use the same signal model across shared hosting, VPSs, WordPress sites, hosted services and external checks.
Client site signals in one browser view
A WordPress-side signal, hosting script, backup result, SSL/DNS check, external reachability check or email-path result can sit in one project view. PMT does not become the client’s site-management platform; it receives selected results and shows the received state.
No predefined stations
A valid first signal can create the station and signal. You do not need to model the estate before proving the path.
No endpoint agent
Starter checks are visible scripts and scheduled tasks. Custom checks stay under your control.
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
Where access is granted, selected projects can be viewed and filtered together in the webapp.
Browser and API access
Use the webapp on desktop or mobile, leave it visible as a lightweight operations screen, or read data through API/CLI access.
When a signal needs attention
You do not investigate inside PMT.
You use the tools that already own the work: WordPress admin, hosting panel, DNS provider, SSL tooling, backup console, logs, email admin, developer tools or the client process.
PMT makes the selected condition visible. Your tools and judgement decide what happens next.
What PMT does not do
- manage content or plugins
- optimise SEO or site performance
- crawl sites comprehensively
- access or control servers
- run commands remotely
- collect broad performance metrics
- diagnose causes
- replace hosting, CMS or developer tools
It reflects selected signals and whether they continue.
Why it stays small
Client sites already generate enough noise: plugin warnings, update churn, hosting quirks, crawler errors and transient performance issues.
PMT is for selected signals that represent conditions worth seeing.
A useful web setup starts small and grows only where another signal is justified.
Inspect the details
Check definitions should make clear:
- what each check represents
- what it does not represent
- where it can mislead
- when not to use it
Choose the next useful path
Starter checks
Start with transparent published checks where they fit the client site or host.
Use your own checks
Send outcomes from scripts, jobs, cron tasks, APIs, hosting panels or external checks.
How it works
See the signal model, token use, stations, signal names, values, cadence and absence.
Get your signal
Start with one client site.
Send one selected signal.
Replace the test with something real.
Start small
Use a WordPress plugin signal, external check, backup result, email-path check or your own site script.