Skip to content

Releases: didvc/uptime-mon

v1.0.2

Choose a tag to compare

@didvc didvc released this 29 Aug 16:32

First public release.

uptime-mon fetches a list of URLs on a schedule, appends every result to a
plain-text file, compresses yesterday's file, and gives you a terminal UI to
read the history with real statistics in it. There is no web server, no
database, no accounts, no plugin system, and no alerting.

What it does

It probes four kinds of target: HTTP status checks, keyword checks against the
response body (including an inverted form), ICMP echo, and plain TCP connects.
Interval, timeout, retry count, accepted status codes, request headers,
redirect policy and TLS verification are all set per target, with a defaults
line so a file of ninety endpoints does not repeat itself. Each endpoint runs
on its own schedule, staggered at startup so targets sharing a period do not
all fire on the same second, and a shared limit caps how many requests are in
flight at once.

Results are held in memory and written every ten minutes as InfluxDB line
protocol, one append-only file per day. Completed days are compressed with zstd
at roughly eightfold, or about 21 bytes per sample. Ninety endpoints at a
sixty-second interval come to around 2.6 MB per day and stay under a gigabyte
for a year. The format works with grep and awk, and anything that reads line
protocol can ingest it if you later want the data in InfluxDB or
VictoriaMetrics. Rotation keys off the timestamp of the data rather than the
wall clock, so a probe that straddles midnight cannot reopen yesterday.

The statistics are computed exactly. Availability is never rounded up to a
flattering 100%. Latency percentiles come from every retained sample by linear
interpolation between order statistics, and cover successful probes only, since
a failing endpoint's ten-second timeouts would otherwise drag the median
somewhere meaningless. How long a probe takes to fail gets its own
distribution, because an instant connection-refused and a slow timeout are
different situations. For spread there is standard deviation, median absolute
deviation (which a single outlier barely moves), and coefficient of variation
(unitless, so a 5 ms endpoint and a 500 ms endpoint can be compared for
steadiness rather than speed), plus interquartile range and skew. Runs of
consecutive failures give downtime, longest outage, MTTR and MTBF. Apdex
condenses latency against a configurable target. Stretches where the collector
itself was not running are detected and reported as gaps instead of counting as
uptime.

The terminal UI lists every endpoint with sparklines that tint where probes
failed, so a fast but broken service does not hide behind a flat green line.
Opening a row shows the full distribution, a braille latency chart at 2×4
resolution per character cell, a colour-graded uptime strip, a breakdown of
failure causes, and recent outages with timestamps and durations. Windows run
from one hour to thirty days.

Point the importer at an Uptime Kuma backup and it converts URLs, names,
intervals, timeouts, retry counts, status-code ranges, keyword checks, headers,
basic auth, redirect limits and tags. Monitor types this tool has no opinion
about are listed individually as skipped, with a reason. The generated file is
re-parsed before it replaces anything.

Why there is no alerting

This is left out on purpose. Notification code is the part of a monitor that
needs credentials, outbound network access, deduplication, escalation policies
and a quiet-hours calendar, and it is the part that wakes you for a blip that
already healed. Run uptime-mon stats -format json from cron and pipe it into
whatever you already use. That is about four lines of shell and it stays under
your control.

Measured

Watching 63 live endpoints at a sixty-second interval: about 18 MB resident, 14
threads, negligible CPU between probes. Summarising a full day of 130,000
samples straight out of zstd takes 0.19 seconds. The binary is around 7 MB. It
has two external dependencies: zstd, which the standard library does not
provide, and x/term for raw mode. The probing, ICMP, statistics, charts and
rendering are standard library.

Install

go install github.com/didvc/uptime-mon@latest

Or download a binary below. Linux, macOS and Windows on amd64; Linux and macOS
on arm64. Verify against checksums.txt.

uptime-mon import -in Uptime_Kuma_Backup.json -out endpoints.txt   # or write your own
uptime-mon check                                                    # dry run, writes nothing
uptime-mon run -tui                                                 # collect and watch

Licensed under MPL-2.0.

v1.0.1

Choose a tag to compare

@didvc didvc released this 29 Aug 16:31

First public release.

uptime-mon fetches a list of URLs on a schedule, appends every result to a
plain-text file, compresses yesterday's file, and gives you a terminal UI to
read the history with real statistics in it. There is no web server, no
database, no accounts, no plugin system, and no alerting.

What it does

It probes four kinds of target: HTTP status checks, keyword checks against the
response body (including an inverted form), ICMP echo, and plain TCP connects.
Interval, timeout, retry count, accepted status codes, request headers,
redirect policy and TLS verification are all set per target, with a defaults
line so a file of ninety endpoints does not repeat itself. Each endpoint runs
on its own schedule, staggered at startup so targets sharing a period do not
all fire on the same second, and a shared limit caps how many requests are in
flight at once.

Results are held in memory and written every ten minutes as InfluxDB line
protocol, one append-only file per day. Completed days are compressed with zstd
at roughly eightfold, or about 21 bytes per sample. Ninety endpoints at a
sixty-second interval come to around 2.6 MB per day and stay under a gigabyte
for a year. The format works with grep and awk, and anything that reads line
protocol can ingest it if you later want the data in InfluxDB or
VictoriaMetrics. Rotation keys off the timestamp of the data rather than the
wall clock, so a probe that straddles midnight cannot reopen yesterday.

The statistics are computed exactly. Availability is never rounded up to a
flattering 100%. Latency percentiles come from every retained sample by linear
interpolation between order statistics, and cover successful probes only, since
a failing endpoint's ten-second timeouts would otherwise drag the median
somewhere meaningless. How long a probe takes to fail gets its own
distribution, because an instant connection-refused and a slow timeout are
different situations. For spread there is standard deviation, median absolute
deviation (which a single outlier barely moves), and coefficient of variation
(unitless, so a 5 ms endpoint and a 500 ms endpoint can be compared for
steadiness rather than speed), plus interquartile range and skew. Runs of
consecutive failures give downtime, longest outage, MTTR and MTBF. Apdex
condenses latency against a configurable target. Stretches where the collector
itself was not running are detected and reported as gaps instead of counting as
uptime.

The terminal UI lists every endpoint with sparklines that tint where probes
failed, so a fast but broken service does not hide behind a flat green line.
Opening a row shows the full distribution, a braille latency chart at 2×4
resolution per character cell, a colour-graded uptime strip, a breakdown of
failure causes, and recent outages with timestamps and durations. Windows run
from one hour to thirty days.

Point the importer at an Uptime Kuma backup and it converts URLs, names,
intervals, timeouts, retry counts, status-code ranges, keyword checks, headers,
basic auth, redirect limits and tags. Monitor types this tool has no opinion
about are listed individually as skipped, with a reason. The generated file is
re-parsed before it replaces anything.

Why there is no alerting

This is left out on purpose. Notification code is the part of a monitor that
needs credentials, outbound network access, deduplication, escalation policies
and a quiet-hours calendar, and it is the part that wakes you for a blip that
already healed. Run uptime-mon stats -format json from cron and pipe it into
whatever you already use. That is about four lines of shell and it stays under
your control.

Measured

Watching 63 live endpoints at a sixty-second interval: about 18 MB resident, 14
threads, negligible CPU between probes. Summarising a full day of 130,000
samples straight out of zstd takes 0.19 seconds. The binary is around 7 MB. It
has two external dependencies: zstd, which the standard library does not
provide, and x/term for raw mode. The probing, ICMP, statistics, charts and
rendering are standard library.

Install

go install github.com/didvc/uptime-mon@latest

Or download a binary below. Linux, macOS and Windows on amd64; Linux and macOS
on arm64. Verify against checksums.txt.

uptime-mon import -in Uptime_Kuma_Backup.json -out endpoints.txt   # or write your own
uptime-mon check                                                    # dry run, writes nothing
uptime-mon run -tui                                                 # collect and watch

Licensed under MPL-2.0.

v1.0.0

Choose a tag to compare

@didvc didvc released this 29 Aug 16:27

First public release.

uptime-mon fetches a list of URLs on a schedule, appends every result to a
plain-text file, compresses yesterday's file, and gives you a terminal UI to
read the history with real statistics in it. There is no web server, no
database, no accounts, no plugin system, and no alerting.

What it does

It probes four kinds of target: HTTP status checks, keyword checks against the
response body (including an inverted form), ICMP echo, and plain TCP connects.
Interval, timeout, retry count, accepted status codes, request headers,
redirect policy and TLS verification are all set per target, with a defaults
line so a file of ninety endpoints does not repeat itself. Each endpoint runs
on its own schedule, staggered at startup so targets sharing a period do not
all fire on the same second, and a shared limit caps how many requests are in
flight at once.

Results are held in memory and written every ten minutes as InfluxDB line
protocol, one append-only file per day. Completed days are compressed with zstd
at roughly eightfold, or about 21 bytes per sample. Ninety endpoints at a
sixty-second interval come to around 2.6 MB per day and stay under a gigabyte
for a year. The format works with grep and awk, and anything that reads line
protocol can ingest it if you later want the data in InfluxDB or
VictoriaMetrics. Rotation keys off the timestamp of the data rather than the
wall clock, so a probe that straddles midnight cannot reopen yesterday.

The statistics are computed exactly. Availability is never rounded up to a
flattering 100%. Latency percentiles come from every retained sample by linear
interpolation between order statistics, and cover successful probes only, since
a failing endpoint's ten-second timeouts would otherwise drag the median
somewhere meaningless. How long a probe takes to fail gets its own
distribution, because an instant connection-refused and a slow timeout are
different situations. For spread there is standard deviation, median absolute
deviation (which a single outlier barely moves), and coefficient of variation
(unitless, so a 5 ms endpoint and a 500 ms endpoint can be compared for
steadiness rather than speed), plus interquartile range and skew. Runs of
consecutive failures give downtime, longest outage, MTTR and MTBF. Apdex
condenses latency against a configurable target. Stretches where the collector
itself was not running are detected and reported as gaps instead of counting as
uptime.

The terminal UI lists every endpoint with sparklines that tint where probes
failed, so a fast but broken service does not hide behind a flat green line.
Opening a row shows the full distribution, a braille latency chart at 2×4
resolution per character cell, a colour-graded uptime strip, a breakdown of
failure causes, and recent outages with timestamps and durations. Windows run
from one hour to thirty days.

Point the importer at an Uptime Kuma backup and it converts URLs, names,
intervals, timeouts, retry counts, status-code ranges, keyword checks, headers,
basic auth, redirect limits and tags. Monitor types this tool has no opinion
about are listed individually as skipped, with a reason. The generated file is
re-parsed before it replaces anything.

Why there is no alerting

This is left out on purpose. Notification code is the part of a monitor that
needs credentials, outbound network access, deduplication, escalation policies
and a quiet-hours calendar, and it is the part that wakes you for a blip that
already healed. Run uptime-mon stats -format json from cron and pipe it into
whatever you already use. That is about four lines of shell and it stays under
your control.

Measured

Watching 63 live endpoints at a sixty-second interval: about 18 MB resident, 14
threads, negligible CPU between probes. Summarising a full day of 130,000
samples straight out of zstd takes 0.19 seconds. The binary is around 7 MB. It
has two external dependencies: zstd, which the standard library does not
provide, and x/term for raw mode. The probing, ICMP, statistics, charts and
rendering are standard library.

Install

go install github.com/didvc/uptime-mon@latest

Or download a binary below. Linux, macOS and Windows on amd64; Linux and macOS
on arm64. Verify against checksums.txt.

uptime-mon import -in Uptime_Kuma_Backup.json -out endpoints.txt   # or write your own
uptime-mon check                                                    # dry run, writes nothing
uptime-mon run -tui                                                 # collect and watch

Licensed under MPL-2.0.