Introduction

Heartbeet monitors whether expected events are still happening in your application. Most monitoring tools alert you when something breaks. Heartbeet alerts you when something stops — the absence of an event that should be there.

What problem does it solve?

Silent failures are the hardest category of production incident to detect:

Your checkout process stops firing events — no error, no exception, no alert from your APM
A nightly cron job quietly stops running after a deployment
A Stripe webhook stops reaching your server because of a misconfigured rule
Form submissions drop 80% after a CSS change breaks the submit button on mobile

None of these produce an error. Your dashboards look fine. Your users suffer in silence.

Heartbeet detects these failures by monitoring the presence of events, not just their correctness.

Core concepts

Term	Definition
Beet	A monitored event stream. One beet = one thing you want to know is still happening (e.g. `checkout.complete`, `cron.daily_report`).
Event	A single ping to Heartbeet’s ingestion endpoint, proving the event occurred.
Baseline	The expected rate for a beet at a given hour and day of the week, learned automatically from real traffic.
Alert	Fired when the current event rate falls below the expected baseline.
Widget	A dashboard visualisation attached to a beet (counter, status, chart, etc.).

How it works in one paragraph

You embed a one-line image beacon — or a curl / fetch call — wherever an important event happens in your code. Heartbeet records each ping and builds a time-aware baseline (separate expected ranges for every hour of every day of the week). When an event stops arriving within its expected window, Heartbeet fires an alert via email or Slack. An optional AI explanation tells you the likely cause and what to do next.

Next steps

Quick Start — get your first beet running in under 5 minutes
How It Works — deep dive into event ingestion, baselines, and anomaly detection
API Reference — ingestion endpoint specification