Back to Blog
2026-07-12 • 6 min read

New in QuietPulse: Public Status Pages, README Badges, and Incident-Style Alerts

QuietPulse started as a simple heartbeat monitor for cron jobs and scheduled tasks.

The core idea is still the same: a job sends a ping after it finishes successfully, and QuietPulse alerts you if that ping does not arrive on time.

The latest update focuses on what happens around that signal.

Scheduled jobs are not only private implementation details. They often support billing syncs, reports, imports, backups, automations, and other workflows that teammates need to trust. When a job is healthy, that status should be easy to show where the job is documented. When a job misses a heartbeat, the alert should carry enough context to start debugging without opening five tabs first.

This release makes QuietPulse more shareable in both directions:

  • public monitor status pages for sanitized job status
  • README badges that link to those public pages
  • setup flows that include badge snippets right after monitor creation
  • richer missed-job alerts for Telegram, email, and webhooks

Public Monitor Status Pages

Every monitored job can now have a public status page.

The page is intentionally sanitized. It shows operational status, not private integration details.

It can include:

  • current monitor state
  • last successful heartbeat
  • next expected heartbeat
  • expected interval
  • grace period
  • checked-at time
  • a small "Monitored by QuietPulse" footer

It does not expose the private heartbeat token. The ping URL still belongs in the job, script, CI secret, or scheduler configuration.

That separation matters because a public status artifact should be safe to share in a README, docs page, issue, or team chat. People should be able to see whether a job is being monitored without getting the URL that lets the job report success.

README Badges That Link to Status

QuietPulse already had status badges, but badges become much more useful when they are connected to a public status page.

A badge can now work as a small operational doorway:

[![QuietPulse status](https://quietpulse.xyz/api/jobs/YOUR-JOB-ID/badge.svg)](https://quietpulse.xyz/status/YOUR-JOB-ID)

That is useful in places where developers already look for operational context:

  • GitHub READMEs
  • internal docs
  • runbooks
  • deployment checklists
  • API documentation
  • project dashboards

For open-source and small SaaS projects, this is also a lightweight trust signal. It shows that the boring background work is not being left to hope and memory.

The badge uses the public job id, not the private heartbeat token. If someone sees the badge URL, they can view status, but they cannot make the monitor look healthy by pinging it.

Setup Flow Now Includes the Badge Snippet

The dashboard setup flow now pairs the heartbeat snippet with a README badge snippet.

That means the first setup path is shorter:

  1. create a monitor
  2. copy the heartbeat snippet into the job or scheduler
  3. copy the README badge into the project docs

The same badge block is also available from the monitor setup dialog later, so you do not have to hunt through a separate screen when documenting an existing job.

This is a small product detail, but it changes the habit QuietPulse encourages.

Instead of treating a monitored cron job as a hidden dashboard row, the product nudges you to document it where future-you and teammates will actually look.

Incident-Style Alerts

Missed-job alerts also got more useful.

Previously, the alert told you that a job missed and showed a last ping time. That was enough to know something was wrong, but not enough to start a useful incident discussion.

Telegram and email alerts now include more debugging context:

  • last successful ping
  • expected run time
  • missed-after time
  • detected-at time
  • suggested checks
  • link to the public monitor status page
  • "Detected by QuietPulse"

The goal is not to make alerts noisy. The goal is to make each alert more complete.

When a scheduled job misses its heartbeat, the first questions are usually predictable:

  • Did the scheduler trigger?
  • Did the job fail before sending the heartbeat?
  • Is the heartbeat URL still configured in secrets or environment variables?
  • Is this a real production issue or a setup problem?

Putting those checks directly into the alert makes the message more useful in Telegram, email, or wherever it gets forwarded.

Better Webhook Payloads

Webhook alerts now carry the same incident-oriented shape.

For job.missed, the payload includes fields such as:

{
  "event": "job.missed",
  "public_status_url": "https://quietpulse.xyz/status/JOB_ID",
  "detected_by": "QuietPulse",
  "job": {
    "id": "JOB_ID",
    "name": "Nightly billing sync",
    "last_ping_at": "2026-07-12T10:00:00.000Z",
    "expected_run_at": "2026-07-12T11:00:00.000Z",
    "missed_after": "2026-07-12T11:05:00.000Z",
    "expected_interval_minutes": 60,
    "grace_period_minutes": 5
  },
  "timeline": {
    "last_successful_ping_at": "2026-07-12T10:00:00.000Z",
    "expected_run_at": "2026-07-12T11:00:00.000Z",
    "missed_after": "2026-07-12T11:05:00.000Z",
    "detected_at": "2026-07-12T11:06:00.000Z"
  },
  "suggested_checks": [
    "Did the scheduler trigger?",
    "Did the job fail before the heartbeat?",
    "Is the heartbeat URL still configured in secrets/env?"
  ]
}

That makes webhooks easier to route into Slack, Linear, GitHub issues, custom dashboards, or incident tooling without writing glue code that reconstructs the same timeline.

What This Is Not Yet

This update does not add immutable incident pages yet.

Right now, alerts link to the public monitor status page. That page reflects the current sanitized status of the monitor. It is useful as a shareable link, but it is not a permanent snapshot of one specific missed run.

A future incident report page could go further:

  • preserve the exact missed-run timeline
  • show notification delivery attempts
  • include sanitized integration hints
  • stay available after the job recovers
  • provide a cleaner artifact for GitHub issues, Linear tickets, or post-incident notes

This release is a step in that direction. The alert now contains the right data and links to a public status surface.

Why This Matters

Cron jobs and scheduled tasks often fail silently because they live outside the main request path.

Nobody notices the billing sync did not run until invoices are wrong. Nobody notices the nightly import stopped until a customer asks why data is stale. Nobody notices the report generator died until Monday morning.

Heartbeat monitoring catches the missing signal. These updates make that signal easier to share, document, and discuss.

The direction for QuietPulse is still deliberately narrow:

  • keep setup simple
  • keep heartbeat tokens private
  • make status safe to share
  • make alerts useful enough to debug from
  • avoid turning cron monitoring into a heavy observability project

If you already have monitors in QuietPulse, this is a good time to add badges to your READMEs and docs.

If you are adding a new monitor, the dashboard now gives you both pieces: the heartbeat snippet for the job and the badge snippet for the place where the job is documented.