The boundary providers stop at

If you rent dedicated servers, your provider almost certainly gives you the out-of-band half of hardware visibility: IPMI or KVM access, power control, bandwidth graphs. That half is read from the BMC, outside your operating system, which is exactly why providers are comfortable offering it: nothing of theirs runs inside your machine.

But the OS knows things the BMC never will. SMART attributes drifting on a disk that still reports PASSED. The correctable ECC error rate creeping up on one DIMM. NVMe wear percentage. A RAID member that quietly dropped. GPU XID events. Whether the kernel has a security update pending that needs a reboot. Most of the signal that predicts a failure, rather than reporting one, lives on the OS side of that boundary.

So the in-OS half usually goes missing. The provider won’t install software inside your OS (correctly: it is your machine), and self-assembling that layer, node_exporter here, smartd there, an alertmanager config nobody wants to own, is the project everyone means to do after the outage.

What “automatable” has to mean

Glassmkr’s position is that this layer should be a product: install an agent, get curated bare-metal alert rules (68 of them, each with a public catalog page), route alerts where your team lives. For fleets, and especially for anyone offering monitoring as part of a platform, “product” has to mean automatable end to end. Not “has a metrics API”: every lifecycle step scriptable, including the one that usually hides behind dashboard clicks, alert-channel configuration.

Here is the whole loop with one write-scoped account key:

# 1. Register the server at provision time; its collector key returns once.
curl -sS -X POST https://app.glassmkr.com/api/v1/servers \
  -H "Authorization: Bearer $ACCT_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: provision-cust4211-web01" \
  -d '{"hostname":"cust4211-web01.example.net","tags":["cust-4211"]}'

# 2. Install the agent on the host with that key.
curl -sf https://glassmkr.com/install.sh | sudo GLASSMKR_API_KEY="$COLLECTOR_KEY" bash

# 3. Route alerts where the team works, then prove delivery.
curl -sS -X POST https://app.glassmkr.com/api/v1/channels \
  -H "Authorization: Bearer $ACCT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"channel_type":"slack","name":"cust-4211","config":{"webhook_url":"https://hooks.slack.com/services/..."}}'

# The test endpoint returns 200 with {"success":false} on a delivery failure,
# so assert on .success or a dead channel passes silently.
curl -sS -X POST "https://app.glassmkr.com/api/v1/channels/$CHANNEL_ID/test" \
  -H "Authorization: Bearer $ACCT_KEY" | jq -e '.success' >/dev/null \
  || { echo "channel test failed: notification did not deliver"; exit 1; }

# 4. Read health and alerts back into your own panel or ticketing.
curl -sS "https://app.glassmkr.com/api/v1/servers/$SERVER_ID/alerts?status=active" \
  -H "Authorization: Bearer $ACCT_KEY"

Two notes on running that safely. The account key is powerful (it can create servers across your account), so keep it in a secret manager and out of shell history and CI logs; it travels as a request header here, and as an argument to enroll below, so it is also briefly visible to local process listing on whatever host makes the call. And step 2 pipes the installer straight into sudo for brevity: if you would rather audit before running anything as root, that installer is ~150 lines of bash you can download and read first (the source is on GitHub), then run; it is the same script either way.

Step 3 is the piece people don’t expect. Notification channels, Slack, Discord, PagerDuty, Telegram, email and generic webhook, are created, updated, tested and deleted over the API, and each channel filters by alert priority. Nothing in the loop touches a browser, and all of it works on every plan.

Test the channel like you test a backup

The test endpoint deserves a sentence on its own. It doesn’t validate the shape of your config; it sends a real notification through the channel, and if delivery fails it returns an error carrying the upstream failure message. A Slack webhook that was valid at setup and revoked eight months later is the classic way to discover, mid-incident, that your alerting was write-only. Pipelines should assert on the test call the way they assert on a restore, not a backup.

The shorter path for host-run automation

If your provisioning is Ansible or cloud-init rather than a control plane calling REST, there is a shorter path: glassmkr-crucible enroll --account-key "$ACCT_KEY" on the host itself registers the server, obtains its collector key and starts reporting: one command in a post-install script. Hosts self-register keyed by a stable machine ID, so re-running the automation, or re-imaging the box, maps back to the same server instead of duplicating it. enroll uses the account key for that one registration call and does not write it to disk; only the per-server collector key lands on the host (mode 0600). Keep the account key in your automation's secret store, not baked into a machine image. The full guide with Ansible and cloud-init examples is at automated fleet onboarding.

The part that has to be boring

An agent inside the OS earns scrutiny, especially on rented hardware, where two parties care what runs there. We keep that part deliberately boring: Crucible is MIT licensed, the source is on GitHub, the installer is ~150 lines of bash, it runs as its own non-root user, communicates over HTTPS only, and ships metrics and alert state, plus small bounded diagnostic excerpts around a failure (for example the last journal lines of a failed service, or a matched kernel dmesg event): no bulk log streaming, no command output, no arbitrary file contents. The collector key that stays on the box can push that one server’s telemetry and nothing else.

Who this is for

If you rent dedicated servers: all of the above works today, on any plan, including the free tier’s 3 nodes. Your provider doesn’t need to participate.

And if you are on the other side of the counter, running a hosting platform: this is the layer your customers keep rediscovering the hard way. A provisioning pipeline can hand every new server over already monitored, with alerts already routed to the customer’s channel of choice. We wrote up how we think about that at glassmkr.com/for-providers, and if you’d like to pilot it with us, email [email protected].