Webhook Notifications in QuietPulse: How to Configure, Test, and Verify Signatures

Webhook notifications are now available in QuietPulse. This guide shows how to configure them from the dashboard, send a test request, understand the payload, and verify signed requests securely.

What Webhook Notifications Do in QuietPulse

Webhook notifications let QuietPulse send an HTTP request to your own endpoint when something important happens.

In the current implementation, the main alert event is:

job.missed

There is also a built-in test event:

webhook.test

This makes webhooks useful if you want to:

forward alerts into your own app
trigger a workflow in n8n, Make, Zapier, or Pipedream
fan out alerts into Slack, Discord, or Teams through your own automation
store missed-job incidents in your internal systems

If Telegram is great for fast personal alerts, webhooks are better when you want QuietPulse to plug into a broader system.

How Webhooks Work in QuietPulse

The actual user flow is simple:

Create or choose a monitored job in QuietPulse
Open the Webhook Notifications section in the dashboard
Paste your webhook URL
Optionally set a signing secret
Save the configuration
Click Send Test
QuietPulse sends signed HTTP requests to your endpoint when a job becomes MISSING

Just like the rest of QuietPulse, the webhook alert is tied to heartbeat monitoring.

That means:

your job sends heartbeat pings after successful runs
QuietPulse expects the next ping based on the interval you configured
if the heartbeat does not arrive in time, the job becomes MISSING
QuietPulse sends a webhook notification to your configured endpoint

Step 1: Add a Webhook URL in the Dashboard

In the dashboard, open Webhook Notifications and paste a destination URL such as:

https://your-app.example.com/quietpulse/webhook

For quick testing, a request inspector like webhook.site also works well.

After you save the configuration, QuietPulse stores that endpoint for your account and shows it back in masked form in the dashboard.

A few important rules apply:

the URL must be a valid HTTP or HTTPS URL
obvious localhost and private-network targets are blocked
QuietPulse uses a short timeout and does not follow redirects

Those restrictions are there to reduce webhook misuse and SSRF-style mistakes.

Step 2: Decide Whether You Want a Signing Secret

The Signing Secret field is optional, but recommended.

This is the part that often causes confusion:

QuietPulse does not send the secret itself in the request body
it uses the secret to compute a signature
your receiver verifies that signature to confirm the request really came from QuietPulse

So if your secret is:

You should not expect to see 111 appear in the JSON payload.

Instead, you will see headers such as:

X-QuietPulse-Signature
X-QuietPulse-Timestamp
X-QuietPulse-Event
X-QuietPulse-Delivery-Id

If a secret is configured, X-QuietPulse-Signature contains an HMAC-SHA256 signature derived from the timestamp and raw request body.

That lets your server reject spoofed requests without exposing the secret in transit.

Step 3: Send a Test Request

After saving the config, click Send Test.

QuietPulse sends a request with:

event type webhook.test
a delivery id
a timestamp
a small test payload

This is the fastest way to confirm:

your endpoint is reachable
your app accepts the request format
your signature verification works if you enabled a secret

If the test succeeds, the dashboard shows a success message.

What QuietPulse Sends

Test event

A test request looks like this in principle:

{
  "event": "webhook.test",
  "delivery_id": "abc123...",
  "occurred_at": "2026-04-19T08:00:00.000Z",
  "message": "This is a test notification from QuietPulse."
}

Missed job event

When a monitored job becomes missing, QuietPulse sends something like:

{
  "event": "job.missed",
  "delivery_id": "abc123...",
  "occurred_at": "2026-04-19T08:05:00.000Z",
  "job": {
    "name": "Nightly backup",
    "last_ping_at": "2026-04-19T06:00:00.000Z",
    "expected_interval_minutes": 60,
    "grace_period_minutes": 5
  }
}

A few deliberate design choices matter here:

the payload is JSON
it includes useful operational context
it does not leak the job token

So you can safely process the alert without exposing the heartbeat endpoint itself.

Headers You Should Expect

Each webhook request can include headers like these:

Content-Type: application/json
X-QuietPulse-Event: job.missed
X-QuietPulse-Delivery-Id: <unique-id>
X-QuietPulse-Timestamp: <unix-ms-or-timestamp-value>
X-QuietPulse-Signature: <hmac-signature>

In practice:

X-QuietPulse-Event tells you what happened
X-QuietPulse-Delivery-Id helps with idempotency or debugging
X-QuietPulse-Timestamp is used during signature verification
X-QuietPulse-Signature lets you authenticate the request if a secret is set

How Signature Verification Works

At a high level, QuietPulse signs:

timestamp.raw_request_body

using HMAC-SHA256 and your configured secret.

Your receiver should:

read the raw request body
read X-QuietPulse-Timestamp
recompute the HMAC using your secret
compare it against X-QuietPulse-Signature

If the values match, the request is authentic.

You do not need this step for basic testing with request inspectors, but you should enable it in production integrations.

Best Practices for Real QuietPulse Setups

To make webhook notifications reliable and easy to debug:

Use a dedicated endpoint for QuietPulse alerts
Keep the receiver fast, return 2xx quickly
Verify signatures if you configured a secret
Log delivery_id for troubleshooting
Route the webhook into Slack, Discord, or incident tools from your own automation layer if needed

A simple pattern is:

QuietPulse sends the webhook
your receiver validates it
your receiver forwards it internally or to external tools

That gives you flexibility without making QuietPulse own every downstream integration directly.

Troubleshooting

Save Configuration fails with a validation error

Make sure the URL is a real HTTP or HTTPS address.

Examples that should work:

https://webhook.site/...
https://your-app.example.com/hooks/quietpulse

Examples that should be rejected:

http://localhost:3000/test
http://127.0.0.1/test
private LAN addresses like 192.168.x.x

I do not see my secret in the payload

That is expected.

The secret is used only to create the signature header. It is not sent back in plaintext.

The test request arrives, but my app rejects it

Usually that means one of these:

your endpoint expects a different content type
your signature verification uses a parsed body instead of the raw body
the shared secret does not match
your app is rejecting non-2xx responses from its own validation layer

I want to use Slack with webhooks

QuietPulse webhooks are generic. The cleanest pattern is usually:

QuietPulse -> your webhook receiver or automation tool
your automation tool -> Slack

That keeps the QuietPulse side simple while still letting you route alerts anywhere.

Why This Feature Matters

Webhook notifications make QuietPulse more useful for teams and automations, not just individual alerting.

Telegram is excellent when you want direct messages.
Webhooks are better when you want programmability.

With both available, QuietPulse can now work as:

a direct alerting tool
an automation trigger
a lightweight incident signal for your own systems

Conclusion

Webhook notifications in QuietPulse are designed to stay simple for users while still being safe enough for real integrations.

Paste a webhook URL, optionally set a signing secret, send a test request, and then let QuietPulse notify your system whenever a monitored job goes MISSING.

If you want a flexible bridge into your own stack, this is the cleanest new way to do it.