A custom plugin can check a process that standard checks do not cover, such as the time since a till last completed a sales upload. AI can draft code, documentation and tests from a specification. That specification must explain what to measure and what missing data means.
Define the check first
In this fictional example, a local process writes a JSON file recording the latest successful upload. The plugin reads it and calculates its age. This checks synchronisation, not the complete health of the till.
{
"store": "ST017",
"asset": "POS03",
"last_success": "2026-10-08T10:00:00+02:00"
}
At 10:20, the last success is 1,200 seconds old. For the exercise, choose WARNING from 600 seconds and CRITICAL from 900 seconds, inclusive. Adapt operational thresholds to upload frequency, opening hours and the process's tolerance. Use scheduling or an explicit rule when uploads are not expected outside business hours.
A development request you can verify
Develop a Python 3 plugin that reads a local JSON file without modifying it.
Required field: last_success, an ISO 8601 timestamp with a timezone.
Calculate age in seconds using a clock that tests can replace.
Options: --file, --warning, --critical. Require 0 < warning < critical.
CRITICAL when age >= critical; WARNING when age >= warning; otherwise OK.
Missing file, invalid JSON, timezone-free or future timestamp: UNKNOWN.
Limit file reads to 64 KiB. Handle errors without a traceback in normal output.
Do not execute commands, modify files or use the network.
Use exit codes 0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN.
Print one status line and an age_seconds performance metric.
Omit the metric for UNKNOWN because no valid measurement is available.
Provide tests for exact thresholds, invalid inputs and inconsistent clocks.
Explain execution under an account without administrative privileges.
Check exit codes and metrics against your monitoring system's contract. For compatible plugins, use the official Monitoring Plugins development guidelines. The invalid-input policy above applies to this local check; connection errors need their own policy in network checks.
Expected results
With the clock fixed at 10:20, the sample should return code 2 and an output equivalent to:
CRITICAL - last successful upload 1200 s ago | age_seconds=1200s;600;900;0;
| Age or condition | Expected state |
|---|---|
| 599 seconds | OK |
| 600 seconds | WARNING |
| 899 seconds | WARNING |
| 900 seconds | CRITICAL |
| Future timestamp | UNKNOWN |
| Timestamp without a timezone | UNKNOWN |
| Unreadable file | UNKNOWN |
This is an acceptance specification, not evidence that generated code passes it. Execute the tests, review the code and check the monitoring output before release.
Introduce the check gradually
Start with fictional files, then copies of operational data. Run the plugin under the actual monitoring account to test permissions. Protect the input file and have its producer update it atomically to avoid partial reads.
Deploy to a limited group of tills and compare alerts with actual uploads. Record the version, thresholds, schedule and rollback procedure. Further plugin generation can follow the same process, with a specification and review for each check.
Practise moving from requirements to a verifiable project in the free Codex and vibe coding course. Full lessons require a free account.