Testing Recurrences and Webhooks

Why test in two phases

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

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. Hosted schedules require at least 60 seconds between consecutive occurrences for each target; unsupported cadences return schedule_cadence_too_frequent.

// 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.

1. Open webhook.site.
2. Copy the generated unique URL.
3. Use it as your schedule webhook URL in rrule.net.
4. Wait for the next occurrence.
5. 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.

Hosted delivery limits

Webhook destinations must be public HTTPS endpoints. rrule.net does not follow redirects, and each delivery has a 30-second timeout that includes reading the response body. Execution history stores only the first 1000 response bytes.

Before saving a destination, rrule.net checks its URL and public DNS records without sending a request to it. A successful check does not confirm that the path exists, its credentials are accepted, or the endpoint will return a successful response.

You may configure up to 20 custom headers. Authentication and application headers are supported, while transport headers and the X-RRule-* namespace are managed by rrule.net. Invalid URLs or headers are rejected with a stable error code and reason.

What to check when nothing arrives