The Hund Blog

A Guide to Webhooks, Custom Metrics, and Cron Monitoring

Most people think of a status page as a passive tool. You give it an endpoint, and it checks that endpoint every minute to see if it responds. If the server says "OK," the status page stays green. If the server times out, the component status turns red.

This "pull" method works great for websites and APIs. But modern infrastructure is more complex than just a public-facing web server. You have background workers processing queues, backup jobs, and data pipelines that run on a schedule.

If your backup agent fails silently, your website will still return a 200 OK status. Your standard monitor will tell you everything is fine, even though critical tasks are failing.

This is where Webhooks come in. Instead of Hund.io pulling data from you, your application pushes data to Hund.io. This inversion of control allows you to monitor the "invisible" parts of your infrastructure.

In this guide, we will look at three powerful ways to use webhooks to make your status page more accurate and useful: the "Dead Man's Switch," custom metrics for performance data, and automated incident triggers.

The Concept: Push vs. Pull

Standard monitoring relies on external availability. We try to reach you from our global network. This confirms that your front door is open.

Webhooks rely on internal reporting. Your system sends a message to a unique Hund.io URL saying, "I am still working," or "Here is the current size of the email queue."

This relates to the Push vs. Pull monitoring debate often discussed in the DevOps community. Think of it as a two-way conversation: sometimes you need to ask your application how it is doing (pull), and sometimes your application needs to speak up and tell you it finished a job (push).

1. Monitoring Cron Jobs with a Dead Man's Switch

The most valuable use case for a webhook is the "Dead Man's Switch."

Imagine you have a script that runs every night at 3:00 AM. If the script crashes, you might not know for weeks. A standard uptime monitor can’t help you here because there is no endpoint to check.

With a webhook, you configure Hund.io to expect a "ping" every 24 hours. If 3:00 AM passes and we haven't heard anything, we can automatically mark the component as "Outage" and alert you.

How to set it up:

  1. Create a Webhook Component in Hund.io.
  2. Enable the Dead Man's Switch option.
  3. Set the interval to 86400 seconds (24 hours).

Now, you just need to add a simple command to the end of your script. If the task succeeds, it sends the signal.

#!/bin/bash
set -euo pipefail

if pg_dump "my_database" > backup.sql; then
  # Notify success
  curl -fsSm 10 --retry 3 -X POST \
    -H "X-WEBHOOK-KEY: YOUR_WEBHOOK_KEY" \
    "https://ops.example.com/state_webhook/watchdog/fe82?status=1"
fi

If the pg_dump fails, the curl command never runs; Hund.io notices the silence and triggers the alert.

2. Visualizing Custom Metrics

Uptime isn't just black and white. While a server might technically be online, it could be struggling. Ideally, you want to show "Degraded Performance" before you hit a full "Outage." Sometimes your service is "up," but running so slowly it feels down.

Hund.io allows you to display metric graphs directly on your status page. While we automatically collect response times for native HTTP checks, you can use webhooks to graph anything your application can measure.

Examples of custom metrics:
* Queue Depth: How many emails are waiting to be sent?
* Signups: How many new users registered in the last hour?
* Server Load: What is the CPU usage on your primary worker?
* Exceptions: How many errors were encountered, and of what type?

To do this, you simply POST a JSON payload to your webhook URL.

curl -X POST https://ops.example.com/state_webhook/metrics/f8b4 \
  -H "X-WEBHOOK-KEY: YOUR_WEBHOOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "metrics": {
      "exceptions_raised": [
        {"y": 1, "c": "Fatal"},
        {"y": 3, "c": "Nonfatal"}
      ],
      "response_time": [
        {"y": 80}
      ]
    }
  }'

By pushing this data every minute, you build a historical graph that shows the health of your system at a glance. It moves your status page from being a simple "traffic light" to a true dashboard of system health.

3. Automating Incidents from CI/CD

Another common source of instability is deployment. New code can introduce new bugs.

You can use webhooks to communicate deployment status to your users automatically. Most CI/CD platforms, like GitHub Actions or GitLab CI, can run a shell command or web request during a build pipeline.

You can configure your build pipeline to update a component status to "Degraded" while a deploy is active, and then flip it back to "Operational" when the deploy finishes. Alternatively, you can make use of the Hund API to create "Maintenance" issues during these deployments, and update them throughout the flow.

Example workflow:
1. Deploy Starts: Pipeline sends a webhook to set status to "Degraded."
2. Deploy Succeeds: Pipeline sends a webhook to set status to "Operational."
3. Deploy Fails: Pipeline sends a webhook to set status to "Outage" or "Degraded" and alerts the team.

This keeps your users informed without your developers needing to log in to the Hund.io dashboard manually during a release.

Security Best Practices

When you use webhooks, you are technically opening a door for data to be pushed into your public status page. It is important to treat your webhook keys like passwords.

  • Keep Keys Secret: Use environment variables (like HUND_WEBHOOK_KEY) for webhook keys, and never commit them to a repository.
  • Rotate Keys: If your team changes or a script is compromised, generate a new webhook key in your Hund.io dashboard immediately.

Changing How You Monitor

Adopting a "push" mindset opens up a new layer of visibility. It allows you to monitor the internal processes that power your business, not just the external APIs that serve your customers.

By combining the Dead Man's Switch for background jobs and custom metrics for performance data, you ensure that your status page tells the whole story.

→ Try webhook monitoring with Hund.io for 30 days