Testing Recurrences and Webhooks

A practical workflow to validate your schedule logic first, then verify real webhook deliveries. This guide uses rrule.net simulation plus two external tools: webhook.site and ntfy.sh.

Why test in two phases

Scheduling bugs and delivery bugs are different problems. If you test both at once, diagnosis is slower.

Phase	Goal	Tool
1. Schedule logic	Confirm dates/times are correct (DST, weekday rules, monthly rules)	rrule.net `simulate`
2. Delivery	Confirm webhook is actually called and payload is what you expect	webhook.site / ntfy.sh

Step 1 — Validate and simulate

Before creating a schedule, run validate and simulate. Make sure the next occurrences match your intent in the selected timezone.

// 1) Validate intent
POST /v1/schedules/validate
{
  "input": "Every weekday at 9am",
  "timezone": "Europe/Paris"
}

// 2) Preview real occurrences before creating
POST /v1/schedules/simulate
{
  "input": "Every weekday at 9am",
  "timezone": "Europe/Paris",
  "count": 10
}

Step 2 — Verify webhook calls with webhook.site

webhook.site gives you a temporary URL and captures every incoming request.

Open webhook.site.
Copy the generated unique URL.
Use it as your schedule webhook URL in rrule.net.
Wait for the next occurrence.
Inspect method, headers, and JSON body in webhook.site.

This is the fastest way to confirm the scheduler is triggering and your payload shape is correct.

Step 3 — Use ntfy.sh for quick push confirmation

If you want immediate notification feedback, you can use an ntfy topic URL as the webhook endpoint.

# Subscribe from terminal
curl -s https://ntfy.sh/rrule-net-test-topic/json

Then set your webhook URL to:

https://ntfy.sh/rrule-net-test-topic

Each schedule trigger posts to that topic and appears instantly in your terminal (or mobile app).

Use a random topic name for testing. Do not use predictable/public topics for sensitive data.

What to check when nothing arrives

Schedule status: must be active, not paused.

Next occurrence: confirm it is in the future and within your expected window.

Webhook URL: ensure it is reachable over HTTPS and returns a 2xx response quickly.

Execution history: check response code and response body for failures.

Auto-pause: rrule.net pauses clearly broken endpoints quickly. A 404 usually means the webhook route does not exist or is not active.

n8n: use the production webhook URL and publish/activate the workflow. Test webhook URLs only work while n8n is explicitly listening for a test event.

Recommended order: simulate first, then test delivery with webhook.site, then run a live check with ntfy.sh.

Open Dashboard Idempotent Webhooks