The worst way to learn your backend is down is a customer email. By then the outage has been running an hour, several thousand devices have been unreachable, and your first act of incident response is apologizing rather than fixing. Connected-product companies get one advantage pure software companies do not — the fleet reports on itself continuously — and most fail to use it.

Three Layers, Three Different Questions

Monitoring a connected product means watching three things that fail independently.

  • Infrastructure answers whether the machines are alive: CPU, memory, disk, database connections, queue depth, container restarts. Your cloud provider gives you most of this free and it is the least interesting layer, because healthy infrastructure regularly hosts a completely broken product.
  • Application answers whether requests succeed: error rates by endpoint, latency percentiles, authentication failures, message processing lag, job failures. This is where genuine outages live.
  • Fleet answers whether the devices are actually working. Connected device count, heartbeat gaps, firmware version distribution, provisioning success rate, reconnection storms. Nothing in a standard cloud dashboard tells you this — you have to build it, and it is the layer that catches the failures customers feel first.

Heartbeats Are Your Best Sensor

Have every device report in on a fixed cadence — a tiny message carrying device identifier, firmware version, uptime, connection quality, and a rolling error count. One minute is common for mains-powered products; an hour or a day is appropriate for battery devices where every radio wake costs runtime.

Then alert on the aggregate rather than the individual. One device going quiet is a customer with a router problem. Two hundred going quiet in five minutes is your outage, and the shape of the drop tells you which one it is: a vertical cliff means the broker or the load balancer, a slow decline over an hour means a bad firmware rollout, and a regional pattern means a cloud availability zone or a carrier.

Store heartbeats in a database built for the access pattern. Every device writing a row every minute overwhelms a general-purpose relational table quickly, which is the failure mode described in time-series databases for sensor data. Retain full resolution for a week, rolled-up aggregates for a year, and let the rest expire.

Heartbeat history also underpins the operational tooling your support team needs — the per-device view, the fleet health summary, and the firmware cohort breakdown covered in IoT fleet management.

Define What Working Means Before You Alert

Pick three or four service level indicators that map to something a customer would notice, and set a target on each. For a typical connected product that looks like: percentage of devices connected, measured against a target of 99.5 percent; command round-trip latency at the ninety-ninth percentile, under two seconds; app API success rate above 99.9 percent; and telemetry ingestion lag under thirty seconds.

Those numbers do two useful things. They give you an error budget — at 99.5 percent connectivity you have roughly three and a half hours of degradation per month to spend, and spending it on a planned migration is a legitimate choice. And they settle arguments. "The backend feels slow" is unresolvable; "p99 command latency is 4.1 seconds against a two-second objective" schedules work.

Set targets you can meet. Four nines means fifty-two minutes of downtime per year and demands multi-region failover; most early products should target three nines and say so honestly in their customer agreements. Those same indicators tell you when the architecture itself needs the rework described in scaling an IoT backend.

Alerts That Get Acted On

The failure mode of monitoring is not too few alerts, it is too many. A channel that fires forty times a day becomes wallpaper within a week, and the one alert that mattered scrolls past unread at 2 a.m.

Split alerts into exactly two classes. Pages wake a human and are reserved for things that are both customer-visible and require immediate action: device connection rate dropping more than ten percent below baseline, API error rate above five percent for five minutes, ingestion pipeline stopped, database unreachable. Tickets land in a queue for business hours: disk at seventy percent, certificates expiring in thirty days, an elevated but non-critical error rate, a slow memory leak.

Every page needs three things attached: what the user is experiencing right now, the dashboard link that shows the affected system, and a runbook with the first three diagnostic steps. Alerts without runbooks turn every incident into original research at the worst possible hour. And review the paging history monthly — anything that fired and required no action gets its threshold changed or gets demoted.

Dashboards Somebody Will Actually Read

Build one overview screen that fits on a single display and answers, in five seconds, whether the product is healthy: connected device count against the expected curve, API error rate, command latency, ingestion lag, and the count of open incidents. Everything else belongs on drill-down screens.

Keep this internal view distinct from the console you expose to users, which has a different job entirely, described in what an IoT device dashboard must show.

On-Call Without a Twenty-Person Team

A four-person hardware startup cannot run a follow-the-sun rotation. What works at that size is a weekly rotation with a named primary and backup, a paging service that escalates after ten unacknowledged minutes, an enforced rule that whoever is paged overnight starts late the next day, and a short blameless review after every page that produces one concrete fix.

That last habit makes the rotation survivable: each incident retires one class of alert permanently. Firmware rollouts deserve particular scrutiny, since a staged OTA update is the most common self-inflicted fleet outage, and heartbeat metrics are what tell you to halt one at five percent instead of ninety.

What It Costs

Managed observability platforms bill mostly on data volume: expect $200 to $900 per month for a fleet in the tens of thousands, plus $20 to $30 per user per month for paging. Self-hosting Prometheus and Grafana trades that bill for engineering time you probably need elsewhere. Either way it belongs in the recurring line described in annual software maintenance cost — and the same telemetry stream later powers predictive maintenance, which turns a cost center into a product feature.

Getting Visibility Before Launch

Projects House builds the monitoring, heartbeat, and alerting layer alongside the backend itself, sized to the fleet you expect rather than the one you have. Tell us about your device fleet and uptime commitments through our contact form.