Self-Hosted Service Status Monitor

Engineering & Development

A service status monitor: you list the addresses to check and the conditions to judge them by, it checks them on a schedule and shows each endpoint’s status and response time on a dashboard, and the results are kept on your own machine. You bring it up on your own machine with Docker Compose, the sign-in password is generated at random by a script, and by default it monitors only the service itself. Derived from a frozen snapshot of an open-source project under the Apache-2.0 licence; the delivery adds a single-service orchestration file, a build file that compiles from source, a script that generates the password together with a small hashing tool, and a quick-start guide in Traditional Chinese.

Subscribe & download See how to start

SubscriptionUS$49 per month

Last run2026-11-05

In practice

Readiness4 / 5

What you need

Few changes needed3 / 5

Who it is for

Individual developers and small teams who want to run their own site that checks on a schedule whether their websites and services are up.

How to start

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

Browse the files

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

File overview385 paths

▸alerting91

alert/
config.go
provider/

▸api22

api.go
api_test.go
badge.go
badge_test.go
cache.go
chart.go
chart_test.go
config.go
config_test.go
custom_css.go
…

▸client5

client.go
client_test.go
config.go
config_test.go
grpc.go

▸config53

announcement/
config.go
config_test.go
connectivity/
endpoint/
gontext/
key/
maintenance/
remote/
suite/
…

▸controller2

controller.go
controller_test.go

▸docs1

pagerduty-integration-guide.md

▸jsonpath3

jsonpath.go
jsonpath_bench_test.go
jsonpath_test.go

▸metrics2

metrics.go
metrics_test.go

▸pattern3

pattern.go
pattern_bench_test.go
pattern_test.go

▸quickstart1

config/

▸scripts1

quickstart/

▸security7

basic.go
basic_test.go
config.go
config_test.go
oidc.go
oidc_test.go
sessions.go

▸storage22

config.go
store/
type.go

▸test2

mock.go
ssh.go

▸testdata4

badcert.key
badcert.pem
cert.key
cert.pem

▸tools2

quickstart-hashpw/

▸watchdog6

alerting.go
alerting_test.go
endpoint.go
external_endpoint.go
suite.go
watchdog.go

▸web70

app/
static.go
static/
static_test.go

▫AGENTS.md

▫ATTRIBUTION.md

▫Dockerfile

▫Dockerfile.quickstart

▫LICENSE

▫LICENSE-99LL.md

▫Makefile

▫PRODUCT.md

▫QUICKSTART.md

▫README.md

▫SECURITY.md

▫config.yaml

▫delivery-manifest.txt

▫docker-compose.yml

▫go.mod

▫go.sum

▫main.go

▫Config and hidden files 71

Latest passing run

Clone → Checkout → Toolchain → Build images → Status monitor up and auth

Pre-purchase Disclosure

What you are buying

A self-hosted service status monitor: you list the addresses to check and the conditions to judge them by, and it checks them on a schedule and shows each endpoint’s status and response time on a dashboard. After running the password generation script you bring it up with Docker Compose.

Derived from an open-source project under the Apache-2.0 licence, and not the original project itself. Our work: a build file that compiles from source, an orchestration file, a script that generates the password with a small hashing tool, a configuration file that monitors only itself and a quick-start guide in Traditional Chinese.

Delivery is a frozen snapshot: one zip, taken from the product repository at revision aa81321.

Known limitations

The service is bound to port 8080 of the local machine only; TLS and a reverse proxy are yours to bring
The default configuration checks only the service itself, and addresses you add are checked by the service connecting out to them
No alert is sent by default, and alert channels need your own third-party accounts and keys
Sign-in protects only the interfaces for the status data; the dashboard shell and /health need no sign-in
Endpoint badges, uptime and response times need no sign-in and can be read by anyone who knows the endpoint name
After the configuration file is changed, the container must be restarted for it to take effect
The initialisation script compiles the hashing tool with Docker and needs network access
The data lives in a Docker named volume, and docker compose down -v deletes all check history
The first start compiles from source, fetching from a registry and the Go package repository during that time
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 fae6ede. 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

Execution surface of the delivery reviewed item by item. Our own additions were read: docker-compose.yml (the published port is bound to 127.0.0.1 only; it refuses to start when the sign-in account or the password hash is missing; the configuration folder is mounted read-only; the check results sit in a named volume), quickstart/config/config.yaml (storage is SQLite, it monitors only the service itself, the account and password hash are read from the environment, and no alert is sent by default), Dockerfile.quickstart (the images of the build and run stages are pinned by version and digest, and the run stage runs as a non-root user), and scripts/quickstart/init-env.sh with tools/quickstart-hashpw/main.go (openssl generates a random password, only the URL-safe hashed string is written to .env, .env is mode 600, and an existing one is not overwritten). The upstream Go source was not read file by file; the basis is the Apache-2.0 licence and container isolation.

Script SafetyPASS

The scripts on the buyer’s delivery path were each inspected: init-env.sh and the hashing tool are ours (read); the build goes through Dockerfile.quickstart (read: the Go packages are downloaded from the lock data and compiled, the certificate package is installed from apk, with no download piped straight into a shell). The initialisation script calls docker to compile the hashing tool, so it needs docker and network access.

RecencyPASS

This product is a frozen snapshot and does not follow upstream: the upstream source is pinned to the main-line revision taken on the day the product repository was created (see the evidence link), and the product repository is that snapshot plus our own commits.

LicensePASS

SPDX:LicenseRef-99LL-Product

Upstream LICENSE was checked word for word (the evidence link points at the file itself at the pinned version and matches the copy inside the product repository): the standard Apache License 2.0 text, with no specific copyright holder line; upstream has no NOTICE file. It allows commercial use, modification, derivative works and redistribution, and the licence text requires including the licence and marking the files that were changed (section 4). The decision does not rest on GitHub’s licence field. For the product as a whole the 99LL product licence template is attached: upstream’s LICENSE is kept as it is and LICENSE-99LL.md is added as the sale and liability terms for the part we built, with spdx recorded as LicenseRef-99LL-Product.

Dependency LicensesPASS

This records the declared side, not a scan result: the Go dependencies are declared in go.mod and locked by go.sum, and the packages themselves are fetched from their own repositories when the buyer builds; the base images come from a registry and the certificate package from apk. These dependency trees were not scanned package by package for licences. Upstream has no submodule and no third-party dataset was copied in (see ATTRIBUTION.md).