Heartbeat & stall detection
Register a run, heartbeat while it works, finish when it's done. Miss a heartbeat past the grace window and doneyet raises a stall before anyone notices.
doneyet watches your CI pipelines, cron jobs, and batch workflows. When a run stalls, overruns its window, or fails — you get paged. When it finishes — you see it. No more silent failures.
Free tier, no credit card. Producer libraries are open source (Apache 2.0).
CI runs, k8s CronJobs, ETL, nightly batches — the work that only gets noticed when it silently stops.
Register a run, heartbeat while it works, finish when it's done. Miss a heartbeat past the grace window and doneyet raises a stall before anyone notices.
Stall, overrun, failure, or SLA-at-risk — routed to Slack, PagerDuty, Opsgenie, MS Teams, or a signed webhook. Hysteresis + circuit breakers keep flapping runs from paging twice.
Every workflow and run in one place, with live status, durations, and history. Stop grepping CI logs to answer "did the nightly job run?"
A shell wrapper, a k8s sidecar, a GitHub Actions step, or the dyt CLI. Open-source libraries — wrap an existing job in minutes, no rewrite.
Give a job a deadline. doneyet warns before the SLA is breached and flags overruns, so a "successful" job that ran 3× too long doesn't slip by.
p50/p95 durations, success rates, and a Prometheus endpoint — see a job getting slower before it starts failing.
Watch the data , not just the run. Alert when a table updates late or a load writes the wrong row count — see Pulse ↓
Wrap any job — CI step, cron entry, container — with start / heartbeat / finish. doneyet does the watching.
Your job calls start at the top. doneyet now expects it to finish within its grace + SLA window.
Long jobs ping every few seconds. Go quiet past the grace window and a stall alert fires automatically.
Call finish on success/failure. No finish, no heartbeat? doneyet pages on-call so a dead job never sits silent.
No terminal required. Here's where things live and what to put in the form — full click-by-click walkthrough on the Get started page.
| Field | What to put |
|---|---|
| Name | A human name for the job — e.g. Nightly Export. The slug auto-fills from it (the id your job/CLI references). |
| Check-in grace | How long the run may go silent before doneyet raises a stall. Set it a little above your longest gap between heartbeats — e.g. 2m. |
| Expected duration | Roughly how long a normal run takes — e.g. 10m. doneyet flags runs that overrun it, catching a "succeeded" job that ran 3× too long. |
| Then… | Hit Create, open the workflow's Connect tab for a paste-ready snippet, and wire a channel in Admin → Notifications so breaches reach you. |
A run can say ✓ succeeded and still leave a table stale or half-loaded. Pulse monitors the asset — freshness and row volume — and pages you on the breach a green run hides.
One monitor per asset: freshness_max_lag_s (update by when) and/or a volume floor, ceiling, or anomaly sensitivity . Slack/PagerDuty routing reuses your existing alert rules.
Push: one HTTP call at the end of a pipeline step, from whatever scheduler you run — Airflow, dbt, Dagster, k8s CronJob, a bash line. Bridge: set source_workflow_slug and Pulse derives freshness from that doneyet workflow's last successful run — no producer change.
Stale or off-volume opens one deduped incident and fans out through your channels as on_stale / on_volume . Goes healthy again → it resolves itself. Test paging up front with dyt pulse monitor test .
Already run jobs through doneyet? The bridge gives those assets freshness monitoring for free. Bringing an external scheduler? One observe call wires it — no agent, no polling.
Pulse pricing & how it beats the incumbents →
One flat price per org — not per seat. One pooled allowance of API + workflow calls; pick the tier that fits your volume.
A "call" = one workflow run or one API request. Hard-stop at your plan's allowance (no surprise overage); upgrade any time. Business & Enterprise are billed manually —
Cron monitoring, dead man's switches, and data freshness — the short version.
Cron job monitoring watches your scheduled jobs and alerts you when one fails, stalls, or never runs at all. Instead of grepping logs after the fact, your job checks in with doneyet at the start and end of each run — if it fails or misses its expected check-in, doneyet raises an alert, so a silently failed cron job never goes unnoticed.
A dead man's switch alerts you when something expected stops happening. Your job "checks in" with doneyet on each run; if a check-in never arrives within its grace window, doneyet fires an alert. This catches the worst failure mode — a job that dies silently and simply never runs — which log- or exit-code-based monitoring completely misses.
You wrap a job with three calls: start, heartbeat, and finish. Long-running jobs send a heartbeat while they work; if doneyet stops receiving heartbeats past the grace window, or the job never calls finish, it flags the run as stalled and pages your on-call — before anyone notices the output is missing.
No. doneyet works over plain HTTP, so any job that can make a web request can report in — a shell one-liner, a GitHub Actions step, an Airflow or dbt task, a Kubernetes CronJob, or the dyt CLI. There is no agent, daemon, or polling to run and maintain.
Pulse watches your data assets instead of your jobs. It alerts when a warehouse table updates late (freshness) or writes an unexpected row count (volume) — catching a "successful" pipeline that still left a table stale or half-loaded, a failure that run-level monitoring can't see.
Yes — doneyet has a free plan with no credit card, enough to monitor a handful of workflows and data assets. Paid plans (Starter $29/month, Team $149/month) add more monitors, notification channels, SSO, and Pulse volume-anomaly detection.
Wrap your first job in a few minutes and let doneyet tell you when something's wrong.