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/..."}}'

curl -sS -X POST "https://app.glassmkr.com/api/v1/channels/$CHANNEL_ID/test" \
  -H "Authorization: Bearer $ACCT_KEY"

# 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 every plan, including Free. 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, driver drift across boxes
• 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

68 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 MIT licensed 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: no logs, no command output, no 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.