Back to Blog
2026-06-17 • 5 min read

New in QuietPulse: Setup Templates, Public Badges, and Smarter Job Status

Cron monitoring has two boring but important jobs:

  1. make the first setup hard to mess up
  2. make failures obvious when something goes wrong

The latest QuietPulse updates focus on both.

You can now create common monitor types faster with setup templates, share public status badges without exposing heartbeat tokens, and see clearer status reasons when a job is late, missing, unknown, or newly created.

This is not a rewrite of how QuietPulse monitoring works. Your jobs still send a simple HTTP ping after a successful run. QuietPulse still alerts you when the expected heartbeat does not arrive. The difference is that the product now removes more small points of friction around that workflow.

Setup Templates for Common Jobs

The hardest part of cron monitoring is often not the concept. It is the first two minutes of setup.

You know you need a heartbeat URL, but then you still have to decide:

  • where to put the curl command
  • whether the ping should run before or after the real work
  • how to adapt the example for GitHub Actions, backups, scripts, or scheduled tasks
  • what interval makes sense for the job

QuietPulse now includes one-click setup templates for common monitoring scenarios.

The goal is simple: start from a useful default instead of a blank form.

Templates help when you are creating monitors for jobs like:

  • GitHub Actions scheduled workflows
  • nightly backups
  • recurring scripts
  • data imports
  • report generators
  • cleanup tasks

The important rule stays the same: send the heartbeat only after the job succeeds.

For example, a backup should usually ping QuietPulse after the backup command exits successfully:

/usr/local/bin/backup.sh && curl -fsS "https://quietpulse.xyz/ping/YOUR-TOKEN"

That way, a failed script does not accidentally report itself as healthy.

Templates do not hide that pattern. They make it easier to apply consistently.

Public Status Badges

Public status badges are now available for monitored jobs.

That means you can show a small QuietPulse badge in places where operational status is useful:

  • a GitHub README
  • internal documentation
  • a runbook
  • a deployment checklist
  • a client-facing operations page

The badge is intentionally lightweight. It is not a full status page. It is a quick signal that says whether a monitored job is currently healthy, missing, or unknown.

For example, a README can show that a nightly job is being watched:

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

This is useful for small teams because it moves scheduled jobs out of the "someone probably remembers this exists" category.

If a background task matters enough to monitor, it often matters enough to make visible where the task is documented.

Badge URLs No Longer Expose Ping Tokens

The badge feature also shipped with an important security improvement.

Earlier badge URLs were too close to the heartbeat URL model. That created a bad possibility: if someone had a badge URL based on a real ping token, they could potentially discover the token used to report successful check-ins.

That is not what a public badge should do.

QuietPulse badges now use a public job identifier instead of the private ping token. The heartbeat token remains reserved for the monitored job itself.

The distinction matters:

  • the ping URL is private and lets a job report success
  • the badge URL is public and only reports status

So you can put a badge in a README or docs page without handing out the URL that your job uses to check in.

Old token-shaped badge URLs no longer reveal real job status. If the identifier is not a valid public job id, QuietPulse returns an unknown badge.

Smarter Job Status Reasons

A simple "failed" label is not always enough.

When a scheduled job looks unhealthy, you want to know what kind of unhealthy it is.

QuietPulse now provides clearer status reasons in the dashboard so you can distinguish between cases like:

  • the job has never checked in
  • the job is overdue
  • the monitor is waiting for the first heartbeat
  • the current status is unknown
  • the job has recovered after a late or missing check-in

This sounds small, but it changes the debugging flow.

Without status reasons, every alert starts with the same question:

Did the job fail, or did I configure the monitor wrong?

With clearer reasons, the dashboard can point you in the right direction faster.

For a brand-new monitor, "waiting for first heartbeat" is less alarming than "missing". For an existing hourly job, "overdue" tells you the expected run did not arrive in time. For an invalid public badge id, "unknown" keeps the public surface safe and honest.

The monitoring model is still simple, but the product now explains the state better.

Cleaner Dashboard Actions

The dashboard also got a small usability cleanup.

Job actions are now grouped into a compact actions menu instead of spreading every command across the job card. That keeps the dashboard easier to scan as more features land.

The menu groups actions such as:

  • edit
  • setup
  • badge
  • copy URL
  • delete

Dashboard modals were also cleaned up for mobile screens. The current layout uses a clearer header, a visible close action, and scrollable modal content so setup and badge dialogs are easier to use on small screens.

These are not headline features, but they matter in daily use. Monitoring dashboards should stay quiet and readable until something needs attention.

What This Means for Existing Users

If you already have QuietPulse monitors, nothing about your heartbeat integration needs to change.

Existing ping URLs continue to work. Existing jobs keep checking in the same way. Telegram alerts and webhook notifications continue to use the same monitoring model.

The main improvements are around setup, sharing, and interpretation:

  • new monitors are faster to create
  • public badges are safer to share
  • job state is easier to understand
  • dashboard actions are less cluttered
  • mobile dialogs are easier to use

If you have a job that is already monitored, this is a good time to add a badge to its README or runbook.

If you have a job that is not monitored yet, start with the one that would hurt most if it silently stopped running: backups, billing syncs, imports, report generators, or scheduled GitHub Actions workflows.

The Direction

QuietPulse is still focused on one specific problem: silent failures in scheduled and background work.

The product is not trying to become a full observability platform. It is meant to be the simple heartbeat layer that tells you when a job that should have checked in did not.

These updates keep that direction:

  • fewer steps to create a monitor
  • safer ways to share status
  • clearer explanations when a job is not healthy
  • less dashboard clutter around common actions

Cron monitoring should be easy to set up, easy to trust, and boring most of the time.

That is the point.