Over years of doing infrastructure and security work, I kept writing the same
kind of thing: a single-file Python tool, no third-party dependencies, that does one
job well enough to drop into a cron job and forget about. No framework, no install
step, no virtualenv to maintain on a box you only SSH into twice a year.
Here are five of them, and — more importantly — the specific failure each one exists
to catch.
1. Disk and service health probe
The failure it catches: the two boring outages that actually take services down.
A data directory silently fills up until writes and database transactions start
failing, or a background process exits and nobody notices until a customer emails.
How it works: it takes a list of paths and a list of service/process names,
checks free-space percentage against a threshold and whether each process is alive,
prints a Markdown summary, and returns a non-zero exit code if anything breaches.
That exit code is the whole point — it makes the tool composable with any CI or cron
hook without writing glue.
python disk_service_probe.py \
--paths C:/ D:/ E:/data \
--services nginx postgres my-worker \
--disk-threshold-percent 85 \
--service-down-threshold 1
2. Directory SHA-256 integrity snapshot
The failure it catches: a config directory that drifts. Someone hotfixes a file
on the box during an incident, or a deploy half-applies, and three weeks later nobody
can say which files changed or when.
How it works: walk the tree, hash every file with SHA-256, serialise to a JSON
baseline. Later runs diff current state against that baseline and report added,
removed and modified files. No agent, no database, no daemon — the baseline is just
a file you can commit or archive.
# create the baseline
python dir_snapshot.py snapshot --dir ./configs --output baseline.json
# compare current state against it
python dir_snapshot.py verify --dir ./configs --snapshot baseline.json
The same idea, packaged properly with a hash chain so the record itself is
tamper-evident, is here:
offchain-integrity-verifier
3. USDT receipt verification gate
The failure it catches: trusting a webhook payload, or a screenshot, as proof
that a crypto payment arrived. Both are trivially forged, and by the time you find
out, you have already shipped.
How it works: it is a gate, not a notifier. It checks the claimed transfer
against public on-chain data — recipient address, confirmation depth, amount — and
emits a pass/fail verdict plus a tamper-evident receipt. Read-only: it never holds
a key and never sends a transaction.
python verify_cli.py --selftest
Source: usdt-receipt-verifier
4. Offline log analyser
The failure it catches: gigabytes of raw application log sitting on disk doing
nothing, because building a structured summary by hand with grep — error rates,
traffic troughs, repeated anomaly signatures — is tedious enough that nobody does it
until there is already an incident.
How it works: dependency-free parsing of common structured log formats,
frequency histograms bucketed by time, extraction of repeated anomaly signatures,
Markdown report out. Fully offline, so it is safe to point at logs you are not
allowed to ship to a third-party service.
python log_analyser.py /var/log/app/production.log --output report.md
5. Endpoint availability and latency check
The failure it catches: paying for an external monitoring SaaS to watch a handful
of internal endpoints — which means an account, an agent, an egress path, and alert
noise, for something you could answer in one command from inside the network.
How it works: feed it endpoints as plain text, CSV or JSON. It checks HTTP status
and round-trip time (optionally including transfer time), skips private IP ranges by
default as a safety guard, and writes a Markdown report. Any target failing gives you
a non-zero exit code.
python netcheck.py https://github.com https://cloudflare.com --timeout 5.0 --output netcheck.md
The pattern
Zero dependencies, single file, meaningful exit codes. That combination is what makes
these things survive: they run identically on staging and production, they need no
maintenance window to upgrade, and any of them can be read end to end in one sitting
before you trust it with anything.
Two of the five are published as proper open-source projects
(usdt-receipt-verifier,
offchain-integrity-verifier).
The other three are internal utilities — happy to share the approach if any of these
failure modes sound familiar; open an issue on either repo and I will answer there.
The tools themselves
All three are one file, standard library only, with a test you can run before you
trust them:
- zero-match-guard — fail checks that examined nothing
- usdt-receipt-verifier — verify USDT receipts offline
- offchain-integrity-verifier — prove a report was not altered
Available for hire. I build this kind of tooling to order: ops automation, integrity
and verification tools, and content pipelines. Single file, zero third-party dependencies,
meaningful exit codes, and a test you can run yourself.
zerodeptools on Fiverr
Top comments (0)