Roadmap
What is built, what is next, and what is not
ProbeGlass is a small product on purpose, so this page is short on purpose. Dates are not promises; the order below is what the design already supports cheaply. The documentation's roadmap is the source of truth, and it mirrors the one in the repository.
Nothing here is a subscription feature. Everything already shipped is in the container you pull, under the MIT licence, with no tier above it.
Now
0.2.1 is released, and ghcr.io/j000k3r/probeglass:0.2.1 is the
tag to pin — :dev follows the branch under development. From
0.2.0 the container is the only thing it ships: the archives for macOS,
Windows and FreeBSD are gone, because they promised a way to run this that
nothing described. 0.2.0 added maintenance windows, so a sensor can be told
in advance that it is allowed to be away: the checks it fails in that period
open no incident, send no alert and are left out of the uptime figure, while
the probe keeps running — and a second language, German, as one file, so the
next one is a translation and nothing else. 0.2.1 made a sensor that is
inside a window say so on its own card.
The batch in flight adds three things. A sensor can be told which one it sits behind: while that parent is down it opens no incident of its own, so one power cut is one outage instead of thirty. A sensor, a place and a group's heading can each carry a symbol — twenty-six drawings ship inside the binary and take the colour of the text around them, and an image of your own can be uploaded instead, stored in the one SQLite file with everything else; a group also gets a colour and a place in the order. And the dashboard's own measurements are two scales now, so two things of the same kind are the same size everywhere, instead of fifteen type sizes and eighteen paddings that each looked right where it was written. It is a batch, not a date: it ships when it is tested, in the one container there has always been.
Built and released
0.1.0- HTTP, TCP (with TLS and a send/expect exchange), ICMP ping and DNS sensors, each validated before it is saved.
- A dashboard with five views — cards, a list, a tree by site, a wall of heartbeat tiles and a map — live status over SSE, response-time charts, uptime bars, sparklines, an incident timeline, grouping and tags.
- Three tiers of history: raw for 7 days, hourly for 90 days, daily forever, with exactly one resolution answering any range.
- An incident lifecycle with retries before an incident opens, reminders while it stays open, recovery alerts, and per-incident acknowledgement.
- Six alert channels: Telegram, Discord, Matrix, ntfy, Slack, and signed generic webhooks, with custom message templates.
- First-run setup, bcrypt passwords, an API key, and sensors and channels declared in YAML and re-applied on every start.
- A multi-arch container image — the only thing it publishes — with a test suite across the store, the configuration, the probe engines and the API.
The rest of 0.1.0
0.1.0These were built for the same tag rather than a later one, so a container pull gives you everything above and everything below. In the same batch: a top-bar search that reaches sensors, sites, channels, incidents, probe messages and settings; live updates that patch a single card instead of redrawing the dashboard; a Backup and restore panel that writes settings and sensors — and, if you ask, their history — to one JSON file and reads it back; a step-by-step guide inside every alert channel form; and filters on the incident list by status, sensor, period and text.
- Accounts with roles. Setup creates the first administrator; everyone else is an operator or a viewer.
- Two-factor authentication per account, with a server-drawn QR code and eight one-time recovery codes shown exactly once.
- Settings per account, in named tabs. Theme, accent, density, layout, language and interface mode follow the person rather than the installation, and the page shows the one category you chose rather than all of them in a column.
- A header you build out of widgets. The strip at the top of the dashboard — status ring, uptime, latency, probes, how long it has been monitoring — can be rearranged, added to and emptied: a clock, the recent incidents, the slowest sensors, a small map, a row of shortcuts.
- A simple and an advanced interface, chosen at setup. Simple hides areas and folds fields; it never disables anything.
- A guided tour of the dashboard, driven by a data list of steps, that says out loud which data on screen is invented.
- TLS certificate sensors, reporting the days left and separating a name that does not match, a certificate that has expired, and a chain this host does not trust.
- Docker container sensors — one read-only call to the Engine API for one container: running, health, restart count.
-
SNMP sensors — one
GETof one OID over v2c, checked against a substring or a numeric range. - Example data you can take back out and load again, marked as sample data on every card it appears on.
-
probeglass doctor— one command that says what is wrong with an installation and changes nothing.
Next
0.2.xOrdered by value per unit of work.
- More sensor types. An SSH banner, an SMTP/IMAP greeting, a UDP port, an ICMP TTL/hop sensor, and an HTTP sensor that follows a redirect chain and reports what it found.
- Drag-to-arrange groups. A group's colour and symbol are in; its order is still a number typed in the editor, which works and is not a thing anybody wants to do twice. The side-by-side comparison this item once promised is the tree, the wall and the map, and pinning a sensor to the top is the header you build out of widgets.
- Escalation. A second channel that only fires when an incident is still open after N minutes.
- Import and export. A JSON round-trip of sensors and channels, so a configuration can be versioned or moved — the export half already ships as the Backup and restore panel; what is left is a documented file format and a dry run before an import is applied.
Later
0.3.x and beyond-
A
/metricsendpoint, so a homelab that already runs a monitoring stack can scrape ProbeGlass instead of duplicating the checks it already makes. - A public status page on its own path and its own token, safe to share outside the LAN.
- SLA reports built from the daily rollups that are already kept forever.
- A certificate inventory — every certificate any HTTPS or TLS sensor has seen, sorted by expiry.
- Remote probes — a second instance reporting into the first, for watching the homelab from outside.
- A notification digest instead of only event-driven alerts.
- OIDC login for homelabs that already run an identity provider.
- An optional Postgres backend for instances that outgrow one SQLite file.
Deliberately out of scope
out of scopeSaying no is most of what keeps this small enough to run on the thing it watches.
- Agents and infrastructure discovery. ProbeGlass watches what you tell it to watch; it is not a service-discovery or inventory tool.
- Windows and macOS at all. The container is the only thing that ships; there is no archive to unpack on a desktop.
- A full SNMP poller. Single OIDs over v2c are in, because that is what a switch, a router or a NAS is asked for. A MIB walk, trap receivers and v3 are not.
- Multi-tenancy. One instance, one homelab. Several people can have accounts with different roles, but they all see the same sensors — ProbeGlass assumes one group of people who trust each other with the dashboard. Running two containers is the answer to wanting two.
- Plugins loaded at runtime. The sensor and channel interfaces are the extension point, and they live in the binary where they can be tested.
Suggested
proposalsThese are proposals, not promises — nothing here is scheduled, and some of it may never happen.
- A button in the notification itself. Telegram and Slack can carry a confirmation; asking from a phone beats signing into a dashboard.
- A migration helper. Somebody moving here with twenty sensors elsewhere would otherwise retype them by hand.
- Pause a whole group at once. Today it is one sensor at a time, which is the wrong order of operations during a weekend rebuild.
- A weekly digest as well as event alerts. "Nothing else happened" is the message a quiet system has to be able to send before anybody trusts it.
- Write the configuration file back out. The reverse direction of a backup: the dashboard emits the YAML it otherwise reads, so the version-controlled part of a setup stops being hand-maintained.
- A Gotify channel. The usual self-hosted path in a homelab, and a small channel following the existing pattern.
- A settling time against flapping. A sensor oscillating between two states produces a chain of incidents today; a short hold-down would make it one.
- Who changed what. The moment more than one account works on an installation, the question is foreseeable.
The rules every item is judged against
These are why the project exists, and they are the reason items on this page are ordered the way they are.
- One container, no sidecars. A feature that needs a second process to run is not this feature. A small pure-Go library is a different thing: it ships inside the one binary and costs nothing at run time.
- One SQLite file. A backup stays a file copy.
-
No frontend build step. A change to a
.jsfile is a reload. - The numbers must be right. Uptime percentages, gaps and incident durations are the product. Anything that risks double-counting a probe or hiding a gap loses to anything that does not.