Backup & job signals
Backup, cron and scheduled task results without another agent
Backups, scheduled tasks, cron jobs, syncs, exports and batch processes often already know their own result. PMT gives those selected outcomes somewhere simple to report, and can make missing expected reports visible in the operator view.
The silent failure problem
Some failures report clearly. Others are silent because the thing that should report never ran.
Failure reported
The job ran and sent a bad result.
Nothing reported
The job, scheduler, server or path did not report when expected.
PMT role
Show selected received states, and help make expected silence visible.
Use PMT where the process already knows the result
The best job signal is not a generic “server is up” check. It is a selected outcome from the thing that did the work.
PMT may fit if
- a backup, scheduled task, cron job, export, sync or batch process can report a result
- a missing expected report would change what someone does
- you want visibility without another agent or full monitoring platform
- you need customer, site or project separation
- you want fast rollout and clean rollback for assessment or problem solving
PMT may not fit if
- you expect PMT to run or schedule the job
- you expect PMT to verify restore quality
- you want root-cause diagnosis
- you need broad logs, inventory or performance telemetry
- you need compliance-grade backup evidence or a system of record
PMT reflects selected signals. It does not prove the wider process is healthy.
Two ways to start
Use the simplest reporting path that answers the question. Do not add a platform when one signal is enough.
Use a prepared sender
For a quick assessment or a simple recurring check, use a one-line sender or transparent scheduled task.
This can be useful for client troubleshooting, temporary visibility, or confirming whether a specific process is reporting.
Remove the task cleanly when the assessment or investigation is done.
Use your own job logic
The job decides what the result means: completed, attention needed, failed, unknown, in progress, or a scalar value.
PMT receives the chosen outcome and makes the stored state available in the browser view or through API readback.
Useful backup and job signals
These examples are starting points. The rule is simple: one signal, one useful operational question.
Backup completion
A backup process reports the result it can safely determine. PMT shows the received state; the backup system remains the place for investigation and restore validation.
Windows Scheduled Task
A scheduled task sends a result after running. If it stops reporting, the absence can become visible in the operator view.
Cron or batch job
A cron job, export, sync, ETL step or batch process sends a selected outcome when it completes or fails.
Database or file export
A script checks whether an export completed and reports the chosen result or a scalar such as file age, size or count.
Email or service path
A job checks whether a known path completed and sends one result. PMT does not diagnose which part of the path failed.
Client assessment
Use one or more transparent checks to surface hard-to-reach signals from a client setup, or gather specific data needed to understand a difficult problem. Remove cleanly when done.
Common state conventions
Many PMT checks use simple state values:
-1OK / completed / present-2attention soon-3attention now / failed-4unknown or could not determine-5in progress, where applicable
These are conventions used by checks and display rules. The source owns the meaning.
Scalars can be useful too
A job signal does not have to be only green or red.
A sender may report a scalar such as hours since last backup, file age, queue length, record count, duration, free space, or days until expiry.
Use scalar values where a threshold or range changes action. Do not stream metrics just because they are available.
Simple send examples
Keep tokens in environment variables, registry, protected configuration or a secret store where practical.
curl one-liner
curl -sS "https://ingress.pmtapi.net/v2/?tkn=$PMT_SEND_TOKEN&stn=server-01&sens=backup_result&val=-1"Useful for cron jobs, shell scripts and quick tests.
PowerShell example
$uri = "https://ingress.pmtapi.net/v2/?tkn=$env:PMT_SEND_TOKEN&stn=server-01&sens=nightly_job&val=-1"
Invoke-WebRequest -Uri $uri -UseBasicParsing | Out-NullUseful for Windows scheduled tasks and transparent starter-style checks.
See the job result, then see whether it keeps reporting
A backup job, cron job or scheduled task can report its selected result. Repeated reports allow the webapp/operator surface to show stale or missing expected check-ins where cadence rules are configured.
What this avoids
Backup and job monitoring often becomes noisy because tools try to report everything about the system around the job.
PMT takes the narrower route. It asks the process or local check to report the selected outcome that matters.
If the signal would not change what someone does, it probably does not belong in PMT.
What to avoid
- raw logs
- backup contents
- customer-sensitive filenames
- personal data
- large payloads
- broad performance metrics
- changing the meaning of a signal name
Send the result, not the world around it.
What PMT does not do
- run the backup
- verify restore quality
- repair a failed job
- diagnose the cause
- guarantee every submitted request is stored or displayed
- act as a compliance archive
Keep the tool that owns the process as the source of investigation.
Where to go next
For no-scripting first use, start with starter checks.
For local job logic, use your own checks.
For result readback, use API / CLI access.
Start with one process that should report
Choose one backup, task, cron job or batch process. Send one result. Then decide whether it deserves to repeat.