Branch & Remote Sites
Lightweight branch monitoring for constrained links
Use PMT where a branch server, gateway, scheduled task, device, website check or local process can send one small outbound result. PMT gives selected branch and remote-site conditions somewhere central to appear without an agent, inbound tunnel, discovery scan or remote-control plane.
Branch fit
Start with one site, one source, and one useful signal.
Source
Branch server, gateway, device, website, or local job.
Signal
Small outbound GET or POST result.
View
Browser, mobile, NOC-style view, or API readback.
Why branch and remote sites are different
Branches often have constrained links, partial trust, mixed ownership, limited local IT time, and infrastructure that cannot easily run a full monitoring stack.
PMT does not try to map the site.
It gives selected local checks somewhere small and central to report.
What a first signal might answer
- did the branch gateway report
- did the branch backup complete
- did a scheduled task run
- is a local internet path usable
- did the site service respond externally
- is a key local condition outside range
If the signal would not change what someone does, leave it out.
Two ways to start
Use a transparent starter check where it fits. Send your own signal where local judgement matters.
Deploy a starter check
For Windows branch machines, a starter check can be deployed as a visible scheduled task.
This can suit heartbeat, disk state, reboot pending, update failure checks, or other published check definitions.
Use Group Policy where that is the normal deployment route.
Send a branch-specific signal
A local script, gateway, device, application, NAS, website check, or external checker can decide the result locally and send only the outcome.
The source owns the meaning. PMT receives the selected result.
Before you use PMT for branch visibility
PMT is useful where selected signals are enough. It is the wrong tool if you need discovery, control, broad telemetry, or guaranteed delivery.
PMT may fit if
- the site can send small outbound HTTP requests
- one local condition would change what someone does
- the connection is limited, costly, or unreliable
- you do not want another endpoint agent or control plane
- internal and external checks need to sit in one view
PMT may not fit if
- you need automatic branch discovery
- you need remote remediation or command execution
- you need offline buffering by PMT itself
- you need full network monitoring or performance graphs
- you need safety-critical or life-critical control
PMT reflects selected signals. It does not diagnose causes.
What this is not
PMT does not buffer branch data offline, map the branch network, or replace a full network monitor. It is for selected branch signals where small outbound reporting is enough.
Useful first branch signals
Start with signals that answer one operational question. Do not try to represent the whole branch.
Gateway or site check-in
A branch gateway, router-adjacent host, small server, or local script sends a simple reporting signal.
Useful question: is this source still reporting?
Backup or job result
A branch server, NAS, scheduled task, or local backup job sends its chosen result.
Useful question: did the local process report a result?
External reachability
An external checker or regional node sends a result about a public branch service, website, VPN endpoint, or mail path.
Useful question: can the outside world see the thing that matters?
Local condition
A script sends disk state, power state, UPS/battery value, temperature range, or another selected condition.
Scalar values should represent conditions, not raw data collection for its own sake.
Branch internet path
A local check can send a result about whether a chosen outside service or known endpoint is reachable.
PMT receives the selected result; it does not diagnose the ISP, router, or path.
Field or equipment signal
A remote device, gateway, pump controller, sensor script, or local process can report a chosen outcome or value.
Use only where someone can act on the received state.
Webapp view for branch and remote-site signals
Use the webapp on desktop, mobile or a lightweight operations screen to view selected branch and remote-site signals. Use API/CLI access only where stored signal data needs to feed another report, tool or view.
Useful over constrained links
PMT sends small outbound signals. That can be practical where a full monitoring stack, VPN dependency, or endpoint control plane is too heavy or not acceptable.
This can suit branch offices, remote sites, field networks, island sites, satellite or Starlink links, or customer-owned locations with restricted access.
Do not claim the link is reliable because PMT is small. Treat missing expected signals as information, not reassurance.
Internal and external together
A useful branch view may combine signals from inside the site and outside the site.
- internal scheduled task result
- branch server or gateway check-in
- external website or endpoint check
- backup completion signal
- email-path or service-path result
Each signal should still answer one selected question.
Separate branches or customers at source
Use projects where separation matters: another customer, another branch, another site, or another operational group.
Project-specific send tokens help signals land in the right separated view.
Scoped read tokens can be shared where someone needs visibility into only that project.
Read from the browser or API
The browser view can be used on desktop, mobile, or as a lightweight operations screen.
Where needed, stored signal data can also be read through API/CLI access for your own reports, tools, or operational views.
What PMT does not do
- discover branch devices
- map networks
- open inbound access
- run remote commands
- patch or remediate systems
- diagnose the fault cause
- provide offline buffering unless the sender implements it
- act as a compliance archive
PMT makes selected received states and missing expected signals visible where the sender and webapp/operator rules support that view.
Keep the signal small
For branch use, the temptation is to add everything. That breaks the point.
A good branch signal is narrow, explainable, and tied to an action.
Use PMT for conditions worth seeing, not broad telemetry or reassurance theatre.
Start with one branch signal
Choose one site.
Choose one condition.
Send one small result.
Get your signal
Use a test signal first, then replace it with a real branch or remote-site condition.