Forem: Samed Kahyaoglu

Shipping uptime monitoring to an existing cron product: the decisions I got wrong first

Samed Kahyaoglu — Thu, 23 Apr 2026 14:00:00 +0000

Quick context: I am Samed, founder of Drumbeats — started as a cron and background-job monitoring service, now also does HTTP uptime. This post is the build log of adding uptime monitoring on top of a product that was not originally designed for it. Mostly so the next person doing this can skip the three decisions I had to redo.

The starting point

Drumbeats' existing model was push-based: your cron job pings a unique URL when it runs, we alert you when it does not ping on schedule. Everything in the system — monitors, notification routing, incidents, status pages — assumes "an event happened (or did not)."

HTTP uptime is the opposite. It is pull-based: we make a request every minute, record the result, and alert when things go wrong. Different data model, different billing implications, different failure modes.

The interesting question was not "can I bolt uptime on." The interesting question was "which decisions do I inherit from the cron side, and which do I reject?"

Four decisions mattered. I got two of them right on the first pass, and two of them wrong.

Decision 1: retry logic before alerting (got this right)

A single failed HTTP check should not page anyone. Networks are noisy. Deploys take 30 seconds. Load balancers briefly return 502s during warmup.

I shipped with 3 retries spaced 5 seconds apart before opening an incident. If any retry succeeds, nothing happens. If all three fail, we open the incident and send notifications.

This was the easy call. The hard call was the parameters:

Retry count: 2 is too few (you still get false positives on transient blips), 5 is too many (you are now 25+ seconds late on real outages)
Retry spacing: 1 second is too tight (you are just retrying the same network state), 10+ seconds is too slow (real users are getting errors while you wait)

Three retries at five-second gaps is 15 seconds of delay on a true positive, and it filters almost every false positive I have seen in my own checks over the last six months. If someone wants tighter alerting they can drop the interval to 1 minute; if they want looser, 5 minutes.

I left the retry parameters hard-coded on purpose. Every exposed configuration knob is a support ticket waiting to happen.

Decision 2: billing model (got this wrong first)

My first draft: uptime monitors get a flat monthly cost per monitor, priced by check interval. Cheap at 5-min, more at 1-min.

This was wrong for three reasons:

It created a second billing mental model on top of the existing one (cron uses a usage-based "Beats" system).
It made retries invisible — a flapping endpoint that triggered 3 retries per check would cost me compute I was not charging for.
It meant I had to explain two different pricing systems on the pricing page.

What I shipped instead: every HTTP check consumes 1 Beat. Every retry consumes 1 Beat. Same unit as everything else in the product. A monitor checking every minute uses ~43,200 Beats/month; every 5 minutes uses ~8,640.

The retry billing is the important part. It aligns my costs with my prices. A customer with a perpetually flapping endpoint is doing 4x the checks (check + 3 retries per cycle when failing) and pays 4x the Beats. My infra cost scales linearly, my revenue scales linearly, I never need to care about their error rate.

The thing I got wrong: I initially did not bill for retries. I shipped internally with "retries are free" thinking it was a nice gesture. It was not a nice gesture — it was an invitation for pathological customers. Fixed before launch.

Decision 3: reuse notification plumbing (got this right)

I reused the existing notification-group system instead of building an uptime-specific alerting path.

If a user already has Slack + Email configured for their cron monitors, their uptime alerts go to the same places. No second configuration panel, no "oh, uptime alerts have their own routing rules" surprise.

This decision fell out of the cron-side investment I had already made. The notification-group abstraction was built to be monitor-type-agnostic, and this is the first time I got to cash in on that. If I had hard-coded notification logic into the cron monitor type originally, I would have been paying the cost here.

Decision 4: status page integration (got this wrong first)

My first draft separated uptime monitors and cron monitors on the public status page. Two lists, two headings.

Real-world customer reaction during beta: confusion. Their status page is for their users, who do not care whether a specific check is implemented as a cron ping or an HTTP probe. They care whether "API" or "Payment processing" is up.

I collapsed it into a single operational view. A cron monitor and an uptime monitor can sit under the same status-page component, and the end user sees one health state. Internally I still treat them as different monitor types — they have different schemas, different check runners, different alerting rules — but the public surface is unified.

Lesson I will keep: internal model boundaries should not leak into the customer-facing surface unless they carry genuine customer value. "The implementation type of this check" is not customer-facing value.

What I am not doing yet

Three things I deliberately cut from v1:

Keyword verification (assert response body contains a string)
SSL certificate expiry alerts
Multi-region checks

All three are on the next list. I shipped without them because none of them are the 80% case — the 80% case is "is my URL returning 2xx on schedule," and adding the other three would have doubled the scope of v1 without changing who could adopt it on day 1.

The multi-region one is the interesting one technically. I have a draft design I am sitting on. Will write about it separately.

The honest retrospective

If I were starting over, I would have:

Designed the billing unit first, before writing a single line of the check runner. Every other decision cascades from it.
Prototyped retry behavior against real third-party endpoints earlier. The "3 retries × 5 seconds" number looks obvious in hindsight. It was not obvious from a whiteboard.
Killed the feature if the notification-group abstraction did not exist. Rebuilding that would have doubled the project. Knowing what abstractions you can stand on is half the engineering decision.

If you are adding a new check type to an existing monitoring product, or adding any pull-based feature to a push-based system, my honest advice is: the product decisions are harder than the code. The code is a week. The decisions are three weeks.

Per-seat pricing punishes small teams — here is why I killed it

Samed Kahyaoglu — Tue, 21 Apr 2026 14:00:00 +0000

I run Drumbeats — a cron and uptime monitoring service. A few weeks ago I removed seat caps from every plan, including the free one. This post is not really about that change. It is about the pricing decision I kept avoiding for months, and why I think per-seat pricing is quietly the worst default in B2B developer tools.

The uncomfortable thing about per-seat pricing

Per-seat pricing has one honest virtue: it scales revenue with the size of the customer. A 200-person company pays more than a 5-person team. That is fair, and it is why every investor deck has it.

It also has one deeply dishonest consequence that nobody likes talking about: it makes your customers ration access to the tool they are paying you for.

You have seen it. I have done it. The VP looks at the invoice, sees $8/user/month across 40 seats, and asks "do we really need all of these people on it?" And the answer — for a monitoring tool, an observability dashboard, a staging environment, an internal admin — is almost always "yes, but we can make do with fewer."

So teams make do. The on-call engineer who joined last month does not get added because it would bump the plan tier. The junior who is learning the system gets a shared login. The stakeholder who genuinely needs visibility into deploy health ends up DMing a teammate for screenshots.

The tool that is supposed to give your team visibility into production becomes the tool your team routes around.

What the numbers actually look like

Here is the math I kept running. Take a monitoring tool at the Cronitor-style rate of $5 per user per month on paid plans. A 10-person engineering team:

10 seats × $5 = $50/month in seat fees
Before a single monitor, alert, integration, or feature is paid for

That 10-person team is not the customer anyone is pricing for. The pricing page is designed for the 200-person org where $5 × 200 = $1,000/month is rounding error next to the Datadog bill. The 10-person team is the one feeling every dollar of it.

And that 10-person team is me. And probably you.

When I sat down to design Drumbeats' plans, every per-seat model I sketched did the same thing: it priced out the exact customer I was trying to serve.

Three bad alternatives I considered

Before landing on unlimited, I worked through the usual escapes:

1. Per-seat with a "starter team" free tier. Standard SaaS pattern. The problem: the free tier becomes the onboarding experience, and the onboarding experience is "you will hit a wall." Users who run into the wall on day 2 never become customers on day 30.

2. Tiered seat caps by plan (5 / 25 / 100). This is what I actually shipped originally. It was fine. But every plan is now a negotiation between "the monitoring I need" and "the seats I need," and those two things have nothing to do with each other. A 2-person team can have 500 monitors. A 30-person team might have 20 monitors but want everyone notified on deploys.

3. Free read-only seats, paid write seats. Elegant on paper. In practice it is a support burden: customers cannot figure out why Alice can acknowledge an incident and Bob cannot. The cognitive overhead leaks.

None of these solved the rationing problem. They just moved it.

What I actually shipped

I removed seat caps from every plan. Free, Pro, Business — all unlimited. Invite your whole team, no per-seat fee, no counter ticking up in the corner of the settings page.

Pricing is now based on what the product actually consumes: checks, requests, monitors. The things that cost me money to deliver. Not the number of humans looking at the dashboard.

Revenue still scales with company size, because bigger companies run more monitors and generate more checks. But it scales with usage, not with headcount politics.

The objection I have heard

"What stops a huge company from creating one account and having 500 people share it?"

Nothing. I am fine with it. If that company is running a usage volume that justifies a Business-plan subscription, I am already being paid appropriately. The number of humans inside their Slack workspace is genuinely not my business.

The other objection — "but enterprise buyers expect per-seat line items for their procurement process" — is a real one. My answer is that I am not selling to enterprise procurement today. I am selling to the engineer who needs a monitoring tool that will not punish them for inviting a teammate. When I get to the enterprise stage, I will figure that out then.

The honest tradeoff

Removing seat caps reduces one lever I had for driving upgrades. A team that would have upgraded from Free to Pro purely to get more seats will now stay on Free longer.

I accepted that. The alternative — that the people who actually need the tool cannot use it — is the worse business outcome, even if it looks better in a cohort chart for a quarter.

If you are designing pricing for a developer tool right now, my suggestion is: price the thing your product costs you to deliver. Do not price the humans in the room.

What is the worst per-seat pricing experience you have had as a buyer — the one that made you churn or never adopt? I want to hear the specific examples.

Full post with the changelog framing and tables:
https://drumbeats.io/blog/unlimited-team-seats-on-all-plans

Why We Built Drumbeats for Cron Job Monitoring

Samed Kahyaoglu — Sun, 12 Apr 2026 22:46:00 +0000

Your invoice sender stopped after last Friday's deploy. The nightly backup completed — but 4 hours late. The revenue export has been silently skipping runs for a week.

Nobody got paged. Nobody noticed. Your users did.

That is the gap Drumbeats exists to close.

The problem is not missing tools — it is misaligned ones

Uptime monitors check whether endpoints respond. Log aggregators surface errors after the fact. Neither answers the question that actually matters for scheduled work: did this job run on time, and did it finish?

Most cron monitoring tools technically answer that question. But they come with friction that discourages adoption — complicated APIs, per-monitor pricing that punishes coverage, and setup flows that assume you have a free afternoon.

We kept running into the same pattern: teams would instrument their three loudest jobs, skip the rest, and call it done. The quiet ones — daily syncs, weekly reports, monthly cleanups — stayed unmonitored because the cost and effort did not feel justified.

That is the wrong tradeoff.

What we did differently

One-line integration, no SDK

Drumbeats uses a Ping API. If your job can make an HTTP request, it can talk to Drumbeats. No library, no agent, no SDK install.

# Simplest path — ping on success
curl https://beats.drumbeats.io/v1/ping/YOUR_MONITOR_ID

# Want duration tracking? Add a start signal
curl https://beats.drumbeats.io/v1/ping/YOUR_MONITOR_ID/start
your_job_command
curl https://beats.drumbeats.io/v1/ping/YOUR_MONITOR_ID

Works in Bash, Python, Node, Go, Ruby — anything with curl or an HTTP client.

AI-powered setup in 60 seconds

Instead of reading docs and manually wiring each job, you answer three questions about your stack at drumbeats.io/integrate. Drumbeats generates a ready-to-use prompt. Paste it into Cursor, Claude Code, Codex, or Windsurf — your AI agent scans your repo, creates monitors via the API, and instruments your jobs.

The agent even produces a validation report flagging missing start signals, schedule mismatches, and unconfigured notification groups. You review it, merge, and move on.

Usage-based pricing instead of per-monitor fees

Monitors are free on every plan. You pay in Beats — a usage currency where 1 ping = 1 Beat.

That means a nightly backup that pings once a day costs almost nothing. A high-frequency health check that fires every minute costs proportionally more. The bill follows actual job activity, not how many rows exist in your dashboard.

The practical effect: teams can afford to monitor everything important instead of rationing coverage to stay under a monitor cap.

Free — 50 monitors, 200K Beats/month, no credit card.
Pro — Unlimited monitors, 1M Beats/month, $20/month (Founding Member rate: $10/month locked in for 24 months).
Business — Unlimited monitors, 4M Beats/month, $49/month (Founding Member rate: $24.50/month locked in for 24 months).

Automatic incidents and recovery

When a job misses its schedule or reports a failure, Drumbeats opens an incident and notifies the right people — Slack, Email, Telegram, Webhook, Discord, or browser push. When the job recovers, the incident resolves itself. No manual acknowledgment loop unless you want one.

Public status pages

Every monitor can get its own shareable status page showing uptime, execution history, and incidents. Useful for internal stakeholders, external customers, or compliance.

Who Drumbeats is for

Small and mid-size product teams running scheduled work they cannot afford to lose: billing jobs, data pipelines, report generators, backup scripts, sync tasks, cleanup routines.

If you have a handful of cron jobs and want peace of mind, the free plan covers you. If you are running hundreds of jobs across services, Pro or Business scales with you.

Try it

The fastest path is the AI Setup flow — 60 seconds from zero to instrumented.

If you want to explore the pricing model first, see pricing.

Or just start free and wire up your first monitor in under a minute.

The question we would leave you with: does your current setup make you want to monitor more of your background work, or less? If the answer is less, something is off.

Drumbeats vs Healthchecks.io: An Honest Comparison (2026)

Samed Kahyaoglu — Sun, 12 Apr 2026 22:28:32 +0000

Healthchecks.io is one of the most respected tools in the cron monitoring space, and for good reason. It is open source, self-hostable, has been running in production for years, and its hosted free tier is genuinely useful. If you are evaluating cron job monitoring and Healthchecks.io is on your shortlist, it should be.

We built Drumbeats, so we are biased. This post is upfront about that. It is also upfront about where Healthchecks.io wins — because it does win in some important areas. Developers can smell dishonest marketing, and we would rather earn trust with a fair comparison than lose it with a sales page disguised as a blog post.

Here is what this post covers: an honest side-by-side of Drumbeats and Healthchecks.io — pricing math with real numbers, feature comparison, setup examples, and a clear breakdown of who should use which tool.

Quick Overview

Healthchecks.io is open-source (BSD license) and has been around for years. It is a dead man's switch for scheduled jobs: your job pings Healthchecks on success, and if the ping does not arrive on schedule, you get alerted. It supports /start, /fail, and /log endpoints, duration tracking via start-to-success timing, run ID correlation for concurrent executions, payload attachments up to 100 KB, and SMS alerts via Twilio. The hosted version offers a free tier with 20 checks, a $5/month Supporter tier (same limits), a $20/month Business tier (100 checks), and a $80/month Business Plus tier (1000 checks). You can also self-host the entire thing for free.

Drumbeats is a newer monitoring service focused on the full spectrum of background jobs (& also uptime) — cron jobs, scheduled tasks, queue workers, and event-driven processes. Drumbeats uses usage-based pricing through a unit called Beats: 1 API ping = 1 Beat (plus payload overhead). You pay for actual job activity, not for how many monitors exist. The free plan includes 50 monitors and 200,000 Beats/month. Idle monitors cost nothing.

The fundamental difference is not a feature list — it is a design philosophy. Healthchecks.io is built cron-first: it waits for an expected ping and alerts on silence. Drumbeats treats event-driven jobs as a first-class mode alongside cron, with concurrent execution tracking, flexible run IDs, and larger payload support on paid plans. The pricing model is also different: Healthchecks bills by check count, Drumbeats bills by activity.

The Pricing Math — Four Real Scenarios

No hand-waving. Here are exact calculations using each tool's published pricing.

Healthchecks.io Plans (for reference)

Plan	Price	Checks	Log entries/check	SMS/WhatsApp credits	Phone call credits
Hobbyist	$0/mo	20	100	5/mo	—
Supporter	$5/mo	20	100	5/mo	—
Business	$20/mo	100	1,000	50/mo	20/mo
Business Plus	$80/mo	1,000	1,000	500/mo	100/mo

Drumbeats Plans (for reference)

Plan	Price	Monitors	Beats/month	Payload limit
Free	$0/mo	50	200K	100 KB
Pro	$20/mo ($10 early-access)	Unlimited	1M	1 MB
Business	$49/mo ($24.50 early-access)	Unlimited	4M	2 MB

Scenario 1: 20 monitors, daily jobs, success-only ping

You have 20 cron jobs that run once per day. Each sends a single success ping.

Drumbeats calculation:

20 monitors x 1 ping x 30 days = 600 Beats/month

600 Beats is 0.3% of the free tier's 200,000 monthly allowance.

	Drumbeats	Healthchecks.io
Plan	Free	Hobbyist (Free)
Monitors/Checks	20 of 50 included	20 of 20 — at capacity
Monthly cost	$0	$0

Both free. But Drumbeats has 30 monitors of headroom. Healthchecks.io is at the Hobbyist ceiling — the 21st check requires upgrading to Business at $20/month.

Scenario 2: 50 monitors, hourly jobs, start + success pings

50 jobs running every hour with duration tracking (both tools support start-to-success timing).

Drumbeats calculation:

50 monitors x 2 pings x 24 hours x 30 days = 72,000 Beats/month

72,000 Beats is 36% of the free tier. Still free.

	Drumbeats	Healthchecks.io
Plan	Free	Business ($20/mo)
Monitors/Checks	50 of 50 included	50 of 100 included
Monthly cost	$0	$20
Annual cost	$0	$240

Drumbeats: free. Healthchecks.io: $20/month to get above the 20-check Hobbyist limit.

Lock in your Founding Member rate before spots fill. Drumbeats is offering Founding Member pricing through June 1, 2026 — lock in $10/mo for Pro and $24.50/mo for Business for 24 months. You do not have to decide today, but the rate only applies to signups during the window. If you are comparing tools right now, it is worth locking in the price and evaluating at your leisure. View current pricing

Scenario 3: 100 monitors, hourly jobs, start + success pings

Scaling up. 100 monitors, hourly, with duration tracking.

Drumbeats calculation:

100 monitors x 2 pings x 24 hours x 30 days = 144,000 Beats/month

144,000 Beats fits within the free tier's 200,000 allowance for activity volume, but 100 monitors exceeds the Free plan's 50-monitor limit. All 100 require Pro.

	Drumbeats	Healthchecks.io
Plan	Pro at $20/mo (unlimited monitors, 1M Beats)	Business ($20/mo, covers 100 checks)
Monthly cost	$20	$20
Annual cost	$240	$240

At 100 monitors with hourly jobs, the costs converge — both are $20/month. Drumbeats Pro includes unlimited monitors, 1M Beats, and 1 MB payload limits. Healthchecks.io Business includes 100 checks with 1,000 log entries each and 50 SMS credits/month.

Scenario 4: 500 monitors, every 5 minutes

High-frequency monitoring at scale.

Drumbeats calculation:

500 monitors x 2 pings x 12 runs/hour x 24 hours x 30 days = 8,640,000 Beats/month

8.64M Beats exceeds Business (4M), so you would use Business plus Pay-As-You-Go overage.

	Drumbeats	Healthchecks.io
Plan	Business + PAYG overage	Business Plus ($80/mo, 1,000 checks)
Monthly cost	~$49 + overage	$80
Annual cost	~$588+	$960

Healthchecks.io Business Plus covers up to 1,000 checks cleanly at $80/month. With 500 monitors, you have capacity headroom. Drumbeats Business plus PAYG overage is cheaper here, but with the tradeoff that billing is variable. If budget predictability matters, Healthchecks Business Plus is simpler to forecast at this scale.

The Self-Host Wildcard

Healthchecks.io's strongest pricing argument is self-hosting. If you run the open-source version on your own infrastructure, you get unlimited checks for the cost of a VM. For teams comfortable running and maintaining another service, this is genuinely compelling. The pricing comparison above is entirely moot if self-hosting is on the table — more on this in a later section.

Feature Comparison

Feature	Healthchecks.io (hosted)	Drumbeats
Cron job monitoring	Yes	Yes
Heartbeat monitoring	Yes	Yes
Event-driven job monitoring	Partial (cron-first design)	Yes — first-class mode
Ping API (no SDK required)	Yes	Yes
`/start` endpoint	Yes	Yes
`/fail` / `/failure` endpoint	Yes	Yes
`/log` endpoint	Yes	Yes
Duration tracking	Yes (start → success timing)	Yes (start → success timing)
Concurrent run tracking	Partial (UUID-only `rid` param)	Yes (any string up to 255 chars)
Payload attachments	Yes (up to 100 KB per ping)	Yes (up to 2 MB on Business)
Log history / Log entries per job	100/job (Hobbyist/Supporter), 1,000/job (Business/Business Plus)	100/monitor (Free), 500/monitor (Pro), 1,000/monitor (Business)
Email alerts	Yes	Yes (all plans)
Slack alerts	Yes	Yes (all plans)
Discord alerts	Yes	Yes (all plans)
Telegram alerts	Yes	Yes (all plans)
Webhook alerts	Yes	Yes (all plans)
Browser push alerts	No	Yes (all plans)
SMS alerts	Yes (quota-limited per plan)	No
PagerDuty	Yes	Coming soon (webhook bridge today)
OpsGenie	Yes	Coming soon (webhook bridge today)
Signal, Mattermost, etc.	Yes	No
Public status pages	No (badges only)	Yes (on cron/heartbeat monitors)
Free plan checks/monitors	20	50
Team seats	Unlimited (all plans)	Unlimited (all plans)
AI-powered setup flow	No	Yes
Self-hostable	Yes (BSD license)	No
Open source	Yes	No
Cron expression validation	Yes	Yes
Grace periods	Yes	Yes
Failure tolerance	Yes	Yes

Features Worth Calling Out

Event-driven monitoring as a first-class mode. Both tools support /start, /fail, and /log — the HTTP primitives are similar. The difference is in how each product is designed around them. Healthchecks.io is built around the dead man's switch pattern: a check has an expected schedule, and silence triggers an alert. Event-driven use is possible but it is bolted on. Drumbeats has a dedicated JOB_BASIC monitor type that has no schedule at all — it only alerts when you explicitly report a failure or when a job starts and never finishes. For queue workers, webhook handlers, and on-demand processes, this is the right model.

Concurrent run tracking: flexible vs. UUID-only. Both tools support run IDs to correlate pings from concurrent executions. If your jobs have natural domain identifiers — order IDs, message IDs, import batch names — Healthchecks.io forces you to generate a separate UUID and maintain a mapping back to your domain. Drumbeats accepts any string up to 255 characters directly, so order-12345 or import-2026-04-10 is your run ID. No mapping table.

Payload limits grow with plan. Both tools support payload attachments on pings. Healthchecks.io accepts up to 100 KB per ping on all plans. Drumbeats accepts 100 KB on Free, 1 MB on Pro, and 2 MB on Business. For jobs that produce detailed output — long error traces, processing stats, multi-step pipeline results — the higher limits matter.

Public status pages. Drumbeats includes a public status page (showing job health for stakeholders) on all plans, with custom vanity URLs on Pro and Business. Healthchecks.io offers status badges but not dedicated status pages. Note: on Drumbeats, status pages apply to cron and heartbeat monitors; event-driven monitors are excluded.

SMS alerts. Healthchecks.io supports SMS via Twilio with monthly quotas per plan (5 credits on Hobbyist/Supporter, 50 on Business, 500 on Business Plus). Drumbeats does not currently offer SMS notifications.

AI-powered setup. Drumbeats' AI setup flow takes three questions about your stack and generates a ready-to-paste prompt for Cursor, Claude Code, or Windsurf. The AI agent scans your repo, creates monitors via the API, and instruments your jobs automatically. Setup time: under 60 seconds. Healthchecks.io does not have an equivalent.

Setup Comparison

Both tools use HTTP pings. The integration patterns are similar for cron jobs. Drumbeats adds a native concurrent execution model for queue workers.

Cron job — Bash (Drumbeats)

# Before: unmonitored
0 2 * * * /usr/local/bin/backup.sh

# After: monitored with start + success/failure + duration tracking
0 2 * * * curl -fsS --retry 3 https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID/start \
  && /usr/local/bin/backup.sh \
  && curl -fsS --retry 3 https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID/success \
  || curl -fsS --retry 3 https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID/failure

Cron job — Bash (Healthchecks.io)

# Healthchecks.io: full lifecycle with start + success/failure
0 2 * * * curl -fsS --retry 3 https://hc-ping.com/YOUR_CHECK_UUID/start \
  && /usr/local/bin/backup.sh \
  && curl -fsS --retry 3 https://hc-ping.com/YOUR_CHECK_UUID \
  || curl -fsS --retry 3 https://hc-ping.com/YOUR_CHECK_UUID/fail

Both examples use the same /start + success/failure pattern. Both give you duration tracking.

Python with progress logs (Drumbeats)

import requests

MONITOR = "https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID"

def run_data_import():
    requests.get(f"{MONITOR}/start")
    try:
        for i, batch in enumerate(get_batches()):
            process_batch(batch)
            requests.post(f"{MONITOR}/log", json={
                "payload": f"Batch {i + 1} done: {batch.row_count} rows"
            })
        requests.get(f"{MONITOR}/success")
    except Exception as e:
        requests.post(f"{MONITOR}/failure", json={"payload": str(e)})

Python with progress logs (Healthchecks.io)

import requests

CHECK_URL = "https://hc-ping.com/YOUR_CHECK_UUID"

def run_data_import():
    requests.get(f"{CHECK_URL}/start")
    try:
        for i, batch in enumerate(get_batches()):
            process_batch(batch)
            requests.post(f"{CHECK_URL}/log",
                          data=f"Batch {i + 1} done: {batch.row_count} rows")
        requests.get(CHECK_URL)  # success ping
    except Exception as e:
        requests.post(f"{CHECK_URL}/fail", data=str(e))

Both tools support this pattern. The main difference: Drumbeats accepts structured JSON payloads, Healthchecks.io stores raw text/body up to 100 KB.

Node.js — Queue worker with concurrent run tracking (Drumbeats)

const MONITOR = "https://api.drumbeats.io/v1/ping/YOUR_MONITOR_ID";

// Each job execution gets its own run_id — any string works
async function handleJob(job) {
  const runId = `order-${job.id}`; // human-readable domain ID
  await fetch(`${MONITOR}/start?run_id=${runId}`);
  try {
    await processJob(job);
    await fetch(`${MONITOR}/success?run_id=${runId}`);
  } catch (err) {
    await fetch(`${MONITOR}/failure?run_id=${runId}`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ payload: err.message }),
    });
  }
}

Node.js — Queue worker with concurrent run tracking (Healthchecks.io)

const CHECK_URL = "https://hc-ping.com/YOUR_CHECK_UUID";
const { v4: uuidv4 } = require("uuid");

// Healthchecks.io requires UUID format for rid
async function handleJob(job) {
  const rid = uuidv4(); // must be a canonical UUID
  await fetch(`${CHECK_URL}/start?rid=${rid}`);
  try {
    await processJob(job);
    await fetch(`${CHECK_URL}?rid=${rid}`);
  } catch (err) {
    await fetch(`${CHECK_URL}/fail?rid=${rid}`, {
      method: "POST",
      body: err.message,
    });
  }
}

Both approaches work. The tradeoff: Healthchecks.io requires UUIDs for rid. If your jobs have natural domain identifiers like order numbers or message IDs, you cannot use them directly — you need to generate a UUID per execution and maintain a mapping back to your domain ID to correlate alerts to specific jobs.

Drumbeats AI Setup

Drumbeats offers an AI setup flow — answer three questions about your stack, get a ready-to-paste prompt for Cursor, Claude Code, or Windsurf. The AI agent scans your repo, creates monitors via the API, and instruments your jobs automatically. Setup time: under 60 seconds. Healthchecks.io does not have an equivalent.

Where Healthchecks.io Wins

We said we would be honest. Here is where Healthchecks.io is the better choice.

Self-hostable. Healthchecks.io is open source (BSD license) and you can run the entire stack on your own infrastructure. You get unlimited checks for the cost of a VM — no SaaS bill, no per-check pricing, no vendor dependency, no third-party data concerns. If your organization has strict data sovereignty requirements or you simply prefer owning the stack, this is a genuine and significant advantage. Drumbeats does not offer a self-hosted option.

SMS and phone call alerts. Healthchecks.io supports SMS and WhatsApp alerts via Twilio, plus phone call alerts on Business and Business Plus plans. If your on-call rotation depends on SMS or voice, Healthchecks.io has it built in. Drumbeats does not currently offer SMS or phone call notifications.

More notification integrations. Healthchecks.io supports Signal, Mattermost, Zulip, Spike, PagerDuty, OpsGenie, and more natively. If you use a less common alerting tool, Healthchecks.io is more likely to have a native integration. Drumbeats covers Email, Slack, Telegram, Discord, Webhooks, and Browser Push today — PagerDuty and OpsGenie are on the roadmap, bridgeable via webhooks now.

PagerDuty and OpsGenie native today. If your team is already on PagerDuty or OpsGenie and needs native integration without a webhook bridge, Healthchecks.io has it now. Drumbeats has these on the roadmap but they are not yet native.

Predictable per-check pricing at scale. At high check volumes, Healthchecks.io Business Plus ($80/month, 1,000 checks) is a fixed, predictable bill. Drumbeats' usage-based pricing is cheaper for most workloads but introduces variability if job frequency is irregular. For teams that need simple billing forecasting, Healthchecks.io's model is easier to reason about.

If your team is comfortable self-hosting and values open source — Healthchecks.io is a solid choice. No caveats.

Where Drumbeats Wins

More generous free tier. 50 monitors on Drumbeats Free vs. 20 on Healthchecks.io Hobbyist. For teams growing beyond 20 jobs, Drumbeats stays free longer. At 50 monitors, Healthchecks.io requires a $20/month Business plan; Drumbeats is still free.

Event-driven jobs as a first-class mode. Healthchecks.io is designed around schedules. You can use it for event-driven jobs by setting up a check with no expected schedule, but it is not the primary design. Drumbeats has a dedicated event-driven monitor type (JOB_BASIC) that expects no schedule, alerts only on explicit failures or hung runs, and is built specifically for queue workers, webhook handlers, and on-demand tasks. If your background work includes event-driven processes alongside cron jobs, Drumbeats' model fits better.

Flexible run_id format. Both tools support run IDs for concurrent execution tracking. Healthchecks.io requires UUIDs. Drumbeats accepts any string up to 255 characters — meaning you can use your natural domain identifiers (order-12345, import-2026-04-10, msg-abc) as correlation keys without maintaining a separate UUID mapping.

Larger payload limits on paid plans. Both tools support payloads on pings. Healthchecks.io caps at 100 KB across all plans. Drumbeats scales: 100 KB on Free, 1 MB on Pro, 2 MB on Business. For jobs with verbose output — large error traces, pipeline results, multi-stage processing stats — the higher limits matter for debuggability.

Usage-based pricing. A daily job and a per-minute job do not cost the same on Drumbeats. You pay for activity, not existence. Idle monitors cost nothing. This is the right model if your job portfolio is uneven — many low-frequency monitors and a few high-frequency ones — because you only pay for what actually runs.

Public status pages. Drumbeats includes a public status page showing job health on all plans, with custom vanity URLs on Pro and Business. Useful if you need external-facing visibility for stakeholders or customers. Note this applies to cron and heartbeat monitors; event-driven monitors are not included in status pages. Healthchecks.io offers status badges but not full status pages.

AI-powered setup. 60 seconds from zero to fully instrumented. Generate monitor configurations and instrumentation code for your specific stack without manual wiring.

The Self-Host Question

Healthchecks.io's self-hosting option deserves a dedicated section because it changes the comparison fundamentally.

If you self-host Healthchecks.io, the pricing comparison is moot. You get unlimited checks for the cost of a VM (a few dollars/month on most cloud providers). No SaaS bill, no per-check pricing. This is a legitimate advantage.

But self-hosting has real costs that do not show up on a pricing page:

Uptime management. Your monitoring tool needs to be up to monitor your other tools. If Healthchecks.io goes down, you are blind. Who monitors the monitor?
Upgrades and patches. The Healthchecks.io codebase moves forward. Staying current is your responsibility.
Backups. Your monitoring data needs backup. Another thing to manage.
Scaling. If your check volume grows, you need to scale the infrastructure. Database, application server, message queue — all yours.
Ops overhead. Every self-hosted service is a tax on your engineering team's attention. For a small team, running another service may not be worth the savings.

The math depends on your team. If you already have infrastructure management muscle and strong ops practices, self-hosting Healthchecks.io is a great option. If your team is lean and you would rather not manage another service, a hosted solution that costs $0–$20/month is probably the better use of engineering time.

Who Should Use Which

Use Healthchecks.io if:

Self-hosting is a genuine option and your team has the ops capacity for it
You need open-source transparency or have data sovereignty requirements
Your monitoring needs are purely schedule-based (cron, heartbeats)
You need SMS, WhatsApp, or phone call alerts natively today
You need PagerDuty, OpsGenie, Signal, or Mattermost integration natively today
You need predictable per-check billing at scale

Use Drumbeats if:

You run event-driven jobs alongside cron jobs (queue workers, webhooks, on-demand tasks)
You want a more generous free tier (50 monitors vs. 20) with usage-based pricing
Your run IDs are natural domain identifiers (order IDs, message IDs) rather than UUIDs
You need larger payload attachments on paid plans (1–2 MB vs. 100 KB)
You want public status pages for stakeholders included out of the box
Your team is lean and cannot afford to maintain another self-hosted service
You prefer a hosted service with AI-powered setup

For teams running modern backend workloads — a mix of cron jobs, queue workers, and event-driven processes — Drumbeats covers the full spectrum with a design built for that reality. Healthchecks.io is excellent at what it does, but what it does is specifically scheduled job monitoring. If that is all you need, it is a great tool. If you need event-driven support as a first-class feature, the design difference matters.

Try Drumbeats Free

50 monitors. 200,000 Beats/month. All 6 notification channels. No credit card.

Set up your first monitor in 60 seconds: drumbeats.io/register

If you are currently on Healthchecks.io's hosted plans, run the math: count your checks, estimate your ping frequency, and see how it maps to Beats. For most workloads under 50 monitors with hourly-or-less frequency, Drumbeats Free covers it entirely.

Founding Member pricing closes June 1, 2026. We are offering Founding Member rates to a limited number of early adopters — lock in $10/mo for Pro and $24.50/mo for Business for 24 months. Once the window closes or spots fill, new signups pay the standard rate. Start free today — no credit card, no commitment — and upgrade at the Founding Member rate before the window closes.

Start free | View pricing | AI setup in 60 seconds