Zero-Bloat Developer Tools

The Dead-Simple Cron Job Monitor & Heartbeat Alert System

Did your script run? We'll text you if it didn't.

The simplest cron heartbeat and dead man's switch for developers. No complex observability platforms. Just a URL to ping and absolute peace of mind.

3 Steps to Bulletproof Cron Jobs

1.Create a Ping URL

Generate a unique, secure endpoint. Define your expected interval (e.g., every 24 hours) and a grace period.

2.Append to your Code

Add a simple HTTP GET request to the end of your bash script, Node.js task, or Python pipeline.

3.Get Alerted

If our servers do not receive a heartbeat ping from your script in time, we instantly trigger an SMS and Email alert.

Works with any language or framework

No heavy SDKs or dependencies required. Just standard HTTP requests.

cURL (Bash)

curl -m 10 --retry 3 https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID

Python

requests.get('https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID', timeout=10)

Node.js

await fetch('https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID', { signal: AbortSignal.timeout(10000) });

Go

client := http.Client{Timeout: 10 * time.Second}; client.Get("https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID")

Ruby

require 'net/http'; require 'uri'; Net::HTTP.get(URI('https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID'))

PHP

file_get_contents('https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID', false, stream_context_create(['http' => ['timeout' => 10]]));

Java

HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(10)).build().send(HttpRequest.newBuilder().uri(URI.create("https://pingpug.xyz/api/ping/YOUR_UNIQUE_ID")).build(), HttpResponse.BodyHandlers.discarding());

The Anatomy of a Silent Failure: Why "200 OK" Means Nothing

Your database backup script fires up at 11:00 PM on a Friday. Halfway through the pg_dump execution, your server’s /tmp directory runs out of disk space. The script aborts, leaving behind a corrupted, 0-byte SQL file. But the server itself hasn't crashed. You log off for the weekend, completely unaware. It isn't until Tuesday morning, when a bad deployment forces you to restore from a backup, that you realize your safety net has been gone for days.

This is the nightmare of the silent failure.

Traditional uptime monitors (like UptimeRobot or Pingdom) are designed to check if your front door is open. They send a synthetic HTTP GET request to your website every few minutes. As long as your Nginx or Node.js server replies with a 200 OK status, your dashboard glows green and reports 100% uptime.

But traditional pinging is entirely blind to the invisible, asynchronous background tasks actually running your business. Your website can be perfectly healthy while your backend is on fire due to:

  • OOM (Out of Memory) Kills: Your server's RAM spikes while a cron job parses a massive CSV file. The Linux OOM killer silently terminates the background worker to protect the system. The web server stays up, but your data pipeline is dead.
  • Silent API Rate Limits: Your nightly data scraper hits a strict rate limit from a third-party API. It receives a 429 Too Many Requests response. The script halts early without throwing a system-wide exception, meaning no error logs are pushed to your main alerting channels.
  • Full Disks and Expired Tokens: Log files quietly consume your remaining disk space, or an OAuth token for your email queue expires. The cron job attempts to run, instantly fails, and exits.

When background scripts fail, they don't take the website down with them. They fail in the dark.

PingPug flips the traditional monitoring model upside down using a dead man's switch. Instead of pinging your server from the outside and guessing if things are okay, PingPug waits for your code to actively report in. If your script doesn't explicitly tell our servers "I successfully finished the job" within the expected timeframe, we instantly trigger an SMS and Email alert.

Stop trusting 200 OK. Start monitoring what actually matters.


Why I Built PingPug

Hi, I'm Denis, the developer behind PingPug.

A few months ago, I was running a SaaS project and everything looked perfect. My server was up, the landing page was fast, and my standard uptime monitors were glowing green. Then, I checked my Stripe dashboard.

A background cron job responsible for syncing subscription renewals had crashed days earlier due to an unhandled third-party API timeout. Because the main web application was still serving 200 OK responses, none of my traditional monitoring tools caught it. My code was failing silently, and I didn't find out until a customer actually emailed me to ask why their account hadn't renewed.

"I realized that monitoring servers isn't enough; you have to monitor the invisible background tasks that actually run the business."

I needed a simple "dead man's switch" to alert me if my scripts didn't finish. But everything on the market was either a bloated enterprise observability platform, or required installing heavy, language-specific SDKs.

So, I built PingPug. It does one thing perfectly: it listens for a heartbeat from your code, and screams if it goes quiet. No bloat, no complex dashboards. Just absolute peace of mind for solo developers and indie hackers.