Hardware-failure warnings before the ticket lands.

The problem

When a disk dies inside a customer’s dedicated server, the failure becomes your ticket: the emergency migration, the RMA, the customer who found out from an outage. Most of those failures gave notice first. Reallocated sectors climbing for weeks, correctable ECC errors trending up, a PSU quietly dropping out of redundancy.

Provider tooling covers the out-of-band half well. IPMI and KVM access, power control, traffic graphs: table stakes, and most panels do them fine. What the customer doesn’t get is the in-OS half: SMART trend analysis, ECC counters, NVMe wear, RAID state, GPU reliability, kernel and security warnings, with alerting their team can route somewhere they’ll actually see it.

So customers self-assemble that layer, or run without it and open a ticket when the box misbehaves. Glassmkr is that layer as a product: per-server, curated for bare metal, and automatable end to end, so it rides along with your provisioning instead of becoming one more platform to operate.

How Glassmkr fits

What your customers see

Per-server health at a glance: the firing alert with a suggested fix first, then CPU, memory, network errors and IPMI sensors. This is the page a customer opens before they open a ticket.

The whole lifecycle is an API

Monitoring that rides along with provisioning only works if every step is scriptable. Every step is. One write-scoped account key (gmk_acct_live_) drives the loop; the per-server collector keys it returns can only push that server’s telemetry.

# 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. Or skip step 1 entirely:
#    glassmkr-crucible enroll --account-key ... self-registers the host.
curl -sf https://glassmkr.com/install.sh | sudo GLASSMKR_API_KEY="$COLLECTOR_KEY" bash

# 3. Route alerts where the customer's 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} when delivery fails,
#    so assert on .success to make a broken channel fail the pipeline.
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"

Channels are created, updated, tested and deleted over the same API: six types, each filterable by alert priority. All of it works on the hosted instance and self-hosted alike. Reference: channels API; guides: programmatic API and automated onboarding.

The failures it catches early

The rules a hosting fleet cares about most:

• Disk pre-failure: SMART reallocated and pending sectors trending, NVMe wear bands, NVMe Critical Warning; the signals that often precede a disk RMA by days or weeks
• Memory pre-failure: correctable ECC error rate trending up, MCE events; the classic leading indicator of a DIMM swap
• Power and cooling: PSU redundancy loss on multi-PSU chassis, fan failures, temperature thresholds, SEL critical entries from the BMC
• Arrays and filesystems: degraded RAID, ZFS pool state, capacity projection (“this volume fills in 9 days”), read-only remounts
• GPU fleets: XID events, GPU ECC, thermal throttling, PCIe link degradation, vBIOS drift between same-model cards in a host
• Network: interface CRC and frame errors (usually a failing cable or SFP), link-speed drops, bond degradation
• Security posture: SSH root login enabled, no firewall configured, pending kernel vulnerabilities; the state customers blame the provider for after an incident

70 rules total, each with a public catalog entry at /docs/rules. Full documentation at /docs.

The agent you can read

Anything a provider recommends installing inside a customer’s OS gets scrutiny, and it should. Crucible is AGPL-3.0-only and on npm; the source is at github.com/glassmkr/crucible and the installer is ~150 lines of bash you can read first. The agent runs as the glassmkr user, never root, 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.

Keys are scoped to match. The collector key on each box can only push that one server’s telemetry, and with enroll the account key is used for a single registration call and never written to disk. What we hold and how we run it is on the trust page.

Or run the whole stack in your own racks

The dashboard is open source under AGPL-3.0-only (github.com/glassmkr/crucible) and the whole stack self-hosts with one docker compose file: dashboard, API, Postgres, ClickHouse. For a provider that changes the shape of the offer. Monitoring becomes something you run on your own infrastructure and hand to customers as part of the product, with no third party in the data path: their SMART trends, ECC counters and journal excerpts travel from their server to a dashboard you operate, and stop there.

The lifecycle above is the same codebase either way, so provisioning automation written against the hosted API works unchanged against your own instance: same enrollment, same channels, same alert reads back into your panel. And when a customer asks where their telemetry goes, the answer is one sentence: it never leaves your network.

Self-host in 10 minutes. The hosted instance at app.glassmkr.com stays available if you would rather prove the value before running it yourself.