Scheduled-Job Monitoring Site — Cron Monitor (Container Edition)

Engineering & Development

A self-hosted monitoring site for cron and background jobs: your jobs send it an HTTP ping on schedule, and when one does not arrive in time the check turns red and an alert goes out; an init script generates the secret key and the administrator account for you, and a sample check is ready to use the moment you log in; a frozen snapshot of a BSD-3-Clause upstream, with a quick-start guide in Traditional Chinese.

Subscribe & download See how to start

SubscriptionUS$49 per month

Last run2026-11-02

In practice

Readiness5 / 5

What you need

Few changes needed5 / 5

Who it is for

Individuals and small teams running scheduled jobs (backups, cron, ETL, scheduled reports): the pain point is "the schedule broke and nobody knew".

How to start

$ sh scripts/quickstart/init-env.sh
$ docker compose up -d --wait

Browse the files

Files in the product repository at the pinned commit. A few house files are left out of the zip.

File overview1,281 paths

▸docker6

.env.example
Dockerfile
README.md
docker-compose.yml
fetchstatus.py
uwsgi.ini

▸hc823

__init__.py
accounts/
api/
front/
integrations/
lib/
local_settings.py.example
logs/
payments/
settings.py
…

▸scripts2

quickstart/

▸static134

css/
fonts/
img/
js/

▸stuff74

bootstrap.sh
bootstrap/
favicon.svg
icons_icomoon_project.json

▸templates217

accounts/
admin/
bad_link.html
badge.svg
base.html
base_bare.html
base_project.html
contact.vcf
docs/
emails/
…

▫ATTRIBUTION.md

▫CHANGELOG.md

▫CONTRIBUTING.md

▫LICENSE

▫LICENSE-99LL.md

▫PRODUCT.md

▫QUICKSTART.md

▫README.md

▫SECURITY.md

▫SECURITY.upstream.md

▫delivery-manifest.txt

▫docker-compose.yml

▫manage.py

▫mypy.ini

▫requirements-dev.txt

▫requirements.txt

▫search.db

▫Config and hidden files 8

Latest passing run

Clone → Checkout → Toolchain → Container up

Pre-purchase Disclosure

What you are buying

A containerised, self-hosted monitoring site for scheduled jobs: when a job finishes it sends it an HTTP ping, and if nothing has arrived by the scheduled time the matching check turns red and an alert goes out; an init script run before start-up generates the secret key and the administrator account automatically.

A derivative build on top of a BSD-3-Clause open-source Django monitoring service: the compose start-up configuration, the automatic initialisation scripts, the Traditional Chinese quick-start and the product documentation are ours. Delivery is a frozen snapshot: one zip file, taken from the product repository at revision 8f80123.

Known limitations

No TLS termination; serving it publicly means bringing your own domain, reverse proxy and certificate
With no SMTP configured, anything that sends email cannot go out (email alerts, invitations, sign-up mail)
Data lives in a Docker volume, and docker compose down -v deletes the database data along with it
The first start builds the image from source, fetching from Docker Hub, apt and PyPI; it cannot be built in an offline environment
The default URL is bound to localhost; deploying it publicly means changing the domain settings in .env (see the public deployment section of the QUICKSTART)
Pinned to the delivered snapshot; it does not follow upstream.

The liability cap, the scope of what is promised and the statutory floor are governed by the Terms of Service.

Vetting record

Everything below was checked against the pinned commit a2f0af2. Every verdict carries its full reasoning, an evidence link and the checker; failures are published, not hidden — do not take our word for it, verify it yourself.

5 PASS0 WARN0 FAIL

Source ReviewPASS

The execution surface of the delivery was reviewed item by item (in 2026): the files we added were read line by line (the three services in docker-compose.yml, the secret-key generation in init-env.sh, the idempotent account creation in ensure_admin.py), and the secret key is generated at random, not hard-coded. Upstream's Python source was not read file by file; the basis is its high adoption at the time of vetting, the fact that the same people run it as a SaaS themselves, pinned versions in requirements, and container isolation (only web opens a port outward, and the database is not exposed); the SECRET_KEY and the database password are generated separately for each installation.

Script SafetyPASS

Every script that runs on the buyer's delivery path was inspected one by one (in 2026): init-env.sh and ensure_admin.py are ours (reviewed line by line); docker build uses upstream's docker/Dockerfile (read line by line: apt-get installs the build dependencies, then pip wheel and collectstatic — no curl|sh style download-and-run); container start-up is driven by uwsgi.ini with manage.py migrate and attach-daemon, both of which are upstream's own production deployment path. Installing with pip does execute the build scripts of the PyPI packages.

RecencyPASS

Checked directly on the day the product repository was opened (in 2026): upstream was not archived and had a new push that same day; the pinned a2f0af2d was upstream's master HEAD that day.

LicensePASS

SPDX:LicenseRef-99LL-Product

Upstream's LICENSE was read word for word (the evidence URL points at the file itself at the pinned commit): the standard BSD-3-Clause text, Copyright (c) 2015, Pēteris Caune and other contributors — commercial use, modification, derivative works, redistribution and sale are permitted, and the obligations are to keep the copyright notice and the full licence text (the LICENSE and ATTRIBUTION.md are delivered with the zip) and not to endorse anything in upstream's name (the product name carries no upstream trademark, which the naming convention enforces). This is not determined from GitHub's licence field. For the product as a whole, the 99LL product licence template is attached: upstream's LICENSE is kept verbatim, and LICENSE-99LL.md is added as the sale and liability terms for the part we built; spdx is recorded as LicenseRef-99LL-Product.

Dependency LicensesPASS

The runtime third-party packages (Django BSD-3-Clause, uWSGI GPL-2.0 with a linking exception, psycopg LGPL-3.0, pycurl and others) are fetched by the buyer from PyPI / apt at docker build time and are not redistributed in the zip — the copyleft distribution obligation rests with each publisher.