> Source: https://glassmkr.com/for-providers # Hardware-failure warnings before the ticket lands. The in-OS health layer for the dedicated servers you rent out: SMART trends, ECC errors, PSU redundancy, GPU health. Your customers, or your platform, wire it in over one API. [Install in 2 minutes](https://app.glassmkr.com/register) [View Crucible on GitHubMIT](https://github.com/glassmkr/crucible) 3 nodes free. Prove it on boxes you run yourself before offering it to customers. `curl -fsSL https://app.glassmkr.com/install.sh | bash` Crucible v0.13.26 on npm Baking it into provisioning? Drop `glassmkr-crucible enroll` into your post-install or cloud-init: one account key, every host self-registers by machine ID. See [automated fleet onboarding](/docs/automated-onboarding). ## 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 ### The in-OS half of hardware health. Your out-of-band tooling reads the BMC. Crucible reads the OS: SMART attributes and trends, ECC and MCE counters, NVMe wear, RAID and ZFS state, GPU XID/ECC/thermals, kernel and security signals. The rules are tuned for bare-metal failure modes, not cloud workloads. ### Every step is an API call, including alert channels. Enroll hosts during provisioning with one account key. Create, update, test and delete notification channels (Slack, Discord, PagerDuty, Telegram, email, generic webhook) over the API. Read alerts and trend warnings back into your own panel. No dashboard clicks anywhere in the loop, on any plan. ### Tickets that never get opened. A customer who sees “reallocated sectors rising on disk 3” a week early schedules the swap in a window they choose. The other version of that story is a 3 a.m. outage, an emergency migration and an RMA under pressure: work your support team absorbs. ### An agent your customers can audit. Recommending third-party software inside customers’ machines is a trust decision. Crucible is MIT licensed, published on npm, source on GitHub, runs as a non-root user and ships metrics only. Every alert rule has a public catalog page, so customers can see exactly what it watches before installing anything. ## 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. app.glassmkr.com GPU server gpu-ams-a16-01 Active Polling 5m UPTIME 12d 4h snapshot 38s ago OS & HARDWARE Debian 13 Supermicro AS-2015A CRUCIBLE v0.13.26 IPMI: 14 sensors Alerts1 activea hardware fault caught on this host warning NIC errors on eno2 1h 4m eno2 has logged 160 hardware errors (CRC + frame) and 90 discards: the error ratio crossed 0.1% of packets, usually a failing cable or SFP. Suggested fix`ethtool -S eno2 | grep -iE 'err|crc'` `interface_errors` CPU16 cores16 threads · avg 23% · peak 41% 21% Aggregate load Current 21% Avg core 23% Peak core 41%C5 Threads 16 User 17% System 3% IOWait 1% Per-core load idlebusy Memory 20.4GB 32% of 62.7 GB · swap 0 / 8 GB used 20.4 GB cache 23.3 GB free 19.0 GB Load average16 cores 0.18 1% of capacity 1m 0.18 5m 0.22 15m 0.20 Networksaturation · errors · discards eno110 GbE Saturation0.84% Errors 0 Discards 0 eno21 GbE Saturation19.2% Errors 160 Discards 90 IPMItemperatures · fans CPU1 38°C CPU2 41°C VRM 44°C FAN1 5800rpm FAN2 5700rpm PSU1 168W ## 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](/docs/api#channels); guides: [programmatic API](/docs/programmatic-api) and [automated onboarding](/docs/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](/docs/rules). Full documentation at [/docs](/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](https://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](/trust). ## Pricing reminder $3 per node per month. First 3 nodes free. No card required to install. - A customer with 10 servers: **$21/month** - A 100-box fleet, one account: **$291/month** - 200 boxes: **$591/month** Per server, not per GPU and not per gigabyte of telemetry. Monitoring spend stays proportional to the fleet. [Install now](https://app.glassmkr.com/register) [Talk to us about a pilot](mailto:simon@glassmkr.com) ## Prove it on your own fleet first. Install on a few boxes you operate yourself and watch what fires before you put it in front of customers. The default rules need no configuration. `curl -fsSL https://app.glassmkr.com/install.sh | bash` [Sign up free](https://app.glassmkr.com/register) Building this into a hosting platform, or interested in a design-partner pilot? Email [simon@glassmkr.com](mailto:simon@glassmkr.com) directly. We’re a small team and we work with the people who run the infrastructure.