Integrate heartbeat monitoring into your workflow

App Pulse Check is a heartbeat monitor for background jobs, cron tasks, and scripts. Each monitored check (or job) gets a unique ping URL. When the check runs successfully, it calls that URL to signal it's alive. If pings stop arriving within the expected time window, the check is marked down and your team gets notified.

This is not a traditional HTTP uptime monitoring. You don't point us at a public endpoint and wait for it to respond. Instead, your job tells us it finished which catches silent failures: scripts that crash, crons that never fire, workers that hang, pipelines that stall without raising an error.

What it's for

• Nightly backups and database maintenance scripts
• Scheduled data syncs and ETL pipelines
• Queue workers and background processors
• GitHub Actions or CI jobs that must run on a schedule
• Any recurring task that can fail without anyone noticing

Heartbeat vs. health checks

App Pulse Check exposes GET /health on the API server for monitoring the service itself. Your jobs use GET /ping/:uuid a separate, public endpoint scoped to each check you create.

App Pulse Check gives indie hackers and small teams focused monitoring, everything you need to know when scheduled work stops running without a full observability stack.

Also included

• Web dashboard with live status badges and easily readable relative last-ping times
• Copy-ping-URL workflow i.e. no SDK, no package install
• Per-check Slack and Discord webhook configuration
• Pause checks during planned maintenance
• Configurable interval and grace period per check
• JWT-protected check management API for creating and editing checks, separate from the public ping URL your jobs call (no auth required there)

App Pulse Check offers four plans: Free, Supporter, Enterprise, and Enterprise Plus. New accounts start on Free. Paid tiers unlock higher limits and additional alert channels as they launch.

Ping log retention

Every successful ping creates a log entry on that check's history page. Each plan caps how many entries are kept per check. When a new ping would exceed your plan's limit, the oldest log entries are deleted automatically, both when pings arrive and during a periodic retention cleanup.

On Free and Supporter, up to 100 pings per check are retained. Enterprise and Enterprise Plus retain up to 1,000 per check.

Check limits

Each plan also limits how many checks you can create. The dashboard shows your current usage (for example, "12 / 20 checks"). When you reach the limit, existing checks keep running but you cannot create new ones until you delete a check or upgrade your plan.

See the full comparison on the pricing page.

Get your first check running in about five minutes.

1. Sign up and open the dashboard.
2. Click Create Check and give the check it a name, set an expected interval (seconds between successful runs), and a grace period (extra buffer before we mark it as DOWN).
3. Copy the ping URL from the check row. It looks like https://app.pulsecheck.com/ping/a1b2c3d4-…
4. Add a single HTTP GET at the end of your job, only when the work succeeds. See How to integrate for copy-paste examples.
5. Configure Slack or Discord alerts from the check's Settings page — click Configure alerts and save your webhook URLs. See Alerts for setup steps.
6. Run your job once. The check should move from NEW to Up after the first ping.

The ping endpoint is public and requires no authentication. The UUID in the URL acts as the secret. Treat it like an API key.

Test with curl

curl -fsS -o /dev/null "https://app.pulsecheck.com/ping/YOUR-UUID"

-f fails on non-2xx responses; -sS keeps output quiet but surfaces errors.

Errors

• 404: UUID not found (wrong URL or deleted check)
• 500: server error; retry is safe

When you create a check, you set two timing values that control when a missed ping triggers a down state.

Down detection formula

A check goes DOWN when:
  now > lastPingedAt + intervalSeconds + graceSeconds

A background worker evaluates all non-paused checks every 60 seconds, so detection can lag by up to ~60 seconds after the deadline passes.

Suggested presets

Tip: set the interval slightly above your real schedule if jobs sometimes run a few minutes late.

Each check moves through a simple lifecycle visible on your dashboard.

• NEWCheck created but never pinged. Will not go DOWN until the first successful ping arrives.
• UpLast ping arrived within the expected window. Everything looks healthy.
• DOWNPings stopped arriving on time. A Slack or Discord alert fires if configured.

Pause

Use Pause on the dashboard during planned maintenance, deployments, or migrations. Paused checks are skipped by the evaluation worker and will not be marked DOWN or send alerts.

Add one HTTP GET at the end of your job, only after work completes successfully. Store the ping URL in an environment variable. Never commit it to version control.

Linux cron

# Run backup at 2 AM; ping only if backup succeeds
0 2 * * * /usr/local/bin/nightly-backup.sh && curl -fsS -o /dev/null "$PULSECHECK_URL"

Bash script

#!/usr/bin/env bash
set -euo pipefail

# ... your backup logic ...

curl -fsS -o /dev/null "$PULSECHECK_URL"

Node.js

async function runJob() {
  // ... your work ...
  const res = await fetch(process.env.PULSECHECK_URL);
  if (!res.ok) throw new Error(`Ping failed: ${res.status}`);
}

runJob().catch((err) => {
  console.error(err);
  process.exit(1);
});

Python

import os
import urllib.request

def run_job():
    # ... your work ...
    urllib.request.urlopen(os.environ["PULSECHECK_URL"])

if __name__ == "__main__":
    run_job()

GitHub Actions

jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - name: Run task
        run: ./scripts/nightly-task.sh
      - name: Ping App Pulse Check
        if: success()
        run: curl -fsS -o /dev/null "$PULSECHECK_URL"
    env:
      PULSECHECK_URL: ${{ secrets.PULSECHECK_URL }}

Docker / Kubernetes CronJob

Run your main container command first, then ping in a post-step or wrapper script. In Kubernetes, use an init-style wrapper or chain commands with && so the ping only runs on success.

#!/bin/sh
set -e
/node-app/run-sync.sh
curl -fsS -o /dev/null "$PULSECHECK_URL"

Get notified the moment a check goes DOWN, before your users or downstream systems notice something is wrong.

Setting up Discord alerts

1. In Discord, open your server and go to Server Settings → Integrations → Webhooks.
2. Click New Webhook, choose the channel for alerts, and copy the webhook URL — it starts with https://discord.com/api/webhooks/…
3. Open your check's Settings from the dashboard (click the check name or the settings icon), click Configure alerts, paste the Discord webhook URL, and click Save alert settings.

You can configure Slack, Discord, or both on the same check. Recovery alerts are sent to the same channels when a down check receives a ping again.

Setting up Slack alerts

1. Go to api.slack.com/apps → Create New App → From scratch.
2. Name the app (e.g. AppPulseCheck Alerts) and pick your workspace.
3. In the app settings, open Incoming Webhooks.
4. Turn Activate Incoming Webhooks on.
5. Click Add New Webhook to Workspace, choose a channel, and Allow.
6. Copy the webhook URL from the list it starts with https://hooks.slack.com/services/…
7. Open your check's Settings from the dashboard (click the check name or the settings icon), click Configure alerts, paste the Slack webhook URL, and click Save alert settings.

Alerts are configured per check, so different jobs can notify different channels. An alert fires when a check transitions to DOWN. More channels ship soon, no migration needed when they land.

• Ping after success, not before. A ping at the start of a job will mark it UP even if the job crashes midway.
• Don't ping on failure. Let the missed ping surface the problem — unless you intentionally want failures to look healthy.
• One check per distinct job. Don't reuse one UUID for unrelated tasks.
• Use environment variables. Store PULSECHECK_URL in your secrets manager or CI secrets — never in source code.
• Pause during maintenance. Avoid false alarms when you intentionally stop a job.
• Leave headroom in your interval. If a job usually finishes in 50 minutes but sometimes takes 70, don't set a 3,600-second interval with zero grace.

My check is stuck on NEW

No ping has been received yet. Test manually with curl using the URL from your dashboard. Confirm the UUID is correct and the request returns 200.

My check went DOWN but the job is fine

Your interval may be too tight or the job ran slower than expected. Increase the grace period or interval. Also confirm you're pinging after the work finishes, not before.

I didn't get a Slack or Discord alert

Verify at least one webhook URL is saved in the check's Settings → Configure alertspanel, the URL is valid, and the check isn't paused. Alerts fire on DOWN transitions — not on every evaluation cycle.

Ping returns 404

The UUID is wrong or the check was deleted. Copy a fresh URL from the dashboard.

Status changed late

The evaluation worker runs every 60 seconds. A check may appear DOWN up to a minute after the actual deadline.

Can I ping from multiple places?

Yes — any successful GET to the ping URL updates lastPingedAtand sets status to UP. Use one check per logical job, not per server instance, unless that's intentional.