FOR BARE-METAL COMPUTE
Cloud monitoring never needed to know the fan had failed.
On someone else's hardware a dying host just disappears and a new one arrives. On yours, the fan, the DIMM, the power supply and the bonded link are all yours to notice first.
Free hosted or self-hosted. No agent config to write.
curl -fsSL https://glassmkr.com/install.sh | sudo bash Crucible v1.2.3 on npm
This box shipped from the provider with password root SSH enabled. Nothing was broken yet; it was simply waiting to be found.
EVIDENCE
PermitRootLogin is "yes" and PasswordAuthentication is "yes". Root can be brute-forced over SSH.
NEXT SAFE STEP
Set "PermitRootLogin prohibit-password" in /etc/ssh/sshd_config and restart sshd. Key-based root login still works.
The problem
Most monitoring grew up on instances. It is very good at CPU, memory and request rates, because on rented capacity that is genuinely the whole surface: if the hardware underneath fails, the provider replaces it and you never learn that it happened.
Bare metal puts that layer back in your hands, and it is a layer with its own vocabulary. Correctable ECC errors climbing on one DIMM. A machine check the kernel logged and nobody read. One of two power supplies quietly dropping redundancy so the next feed event takes the box down. A bond that is still up because exactly one slave is carrying it. None of that appears in a CPU graph, and all of it is knowable well before it becomes an outage.
You can assemble it yourself from ipmitool, mcelog, ethtool and a pile of exporters. Most teams have better uses for that week.
How Glassmkr fits
Forty-seven rules apply to an ordinary compute box.
Nine for memory and CPU pressure, ten for the network path, ten from the BMC, six for services and time, ten for kernel and patch state. Every one arrives with the remediation attached, because an alert that tells you a number without telling you what to do is just a louder dashboard.
The BMC is a first-class source, not an afterthought.
Fan failure, CPU temperature, PSU redundancy loss, CMOS battery, and critical entries in the system event log. These are read through a narrow root-owned wrapper with a fixed argument list, because reading a BMC needs privilege and we would rather hand you an auditable one-line wrapper than ask you to run the whole agent as root.
Memory faults, in the two places they show up.
Correctable ECC counted per DIMM so you can tell a rising module from background noise, and uncorrected machine-check exceptions from the kernel. We also flag a chassis whose channels are underpopulated, which is not a fault at all but quietly costs you bandwidth you paid for.
Bare-metal networking, not just "is the interface up".
Bond slave down, LACP partner lost, link negotiated below its expected speed, conntrack table exhaustion, softnet drops, listen-queue overflow. A bonded pair running on one leg looks perfectly healthy from above and has no redundancy left at all.
Patch and kernel state, because it is a fleet property.
Pending security updates, a kernel that needs a reboot to take effect, known vulnerabilities in the running kernel, an OS past end of life, SSH accepting root passwords, no firewall. Boring, unglamorous, and the thing an auditor asks about first.
We alert when the monitoring itself goes blind.
If IPMI stops answering, that is its own alert rather than a quiet gap where hardware alerts used to be. A monitoring tool that goes silent looks exactly like a healthy fleet, and that is the failure mode we are most afraid of.
We tune these against our own fleet
Every rule here runs on the twenty-one bare-metal boxes we operate, which is how the false positives get found. A recent example: a sandbox setting in our own agent made a normal filesystem look read-only, and nineteen of twenty-one hosts carried a permanent critical alert that meant nothing. We found it, fixed it, and verified it went to zero of twenty-one while a genuinely read-only mount still fired.
That is the work nobody sees. An alert set that pages you for benign conditions gets muted within a week, and a muted alert set is worth nothing at all.
The agent you can read
Crucible is AGPL-3.0-only and public. It runs unprivileged, and the handful of privileged reads go through a root-owned wrapper with one fixed command per permitted action: no shell, no caller-supplied arguments. Install is one command and there is no configuration file to write before it works.
What we collect and what we do not is documented separately, in detail.
Pricing reminder
Free both ways: self-hosted under AGPL-3.0-only with no node limits, or the free hosted instance with a 10-node per-account cap. Never per metric, per check or per host-hour.
A 40-core dual-socket box counts the same as a small VPS: one node.
Try it on a few boxes.
Both deployment forms are free with no time limit, which is enough to see whether it tells you anything you did not already know about hardware you own.
Or self-host it
The whole stack is open source under AGPL-3.0-only and runs on your own hardware with one docker compose file; nothing leaves your network.
curl -fsSL https://glassmkr.com/install.sh | sudo bash -s -- \
--api-key "gmk_cru_live_..." \
--ingest-url "http://your-dashboard-host:3000/api/v1/ingest"