Alerts
Send Slack, Discord, or webhook notifications when warmers fail, finish, or show a high error rate.
7 min read
A warmer that quietly stopped working is worse than no warmer at all, because you will assume you are covered. Alerts close that gap.
They are configured under Account → Alerts. You can add as many endpoints as you like.
Alert types
| Type | Use it for |
|---|---|
| Slack | An incoming webhook posting into a Slack channel. |
| Discord | A Discord channel webhook. |
| Generic webhook | Any HTTP endpoint you control — your own service, an incident tool, or an automation platform. |
Events
- Crawl error
- A warm run failed. This is the one everybody should enable — it is the difference between knowing and assuming.
- Crawl completed
- A run finished. Useful as an audit trail or to confirm a post-deploy warm actually happened. Noisy on frequent schedules.
- High error rate (≥25%)
- A run completed but at least a quarter of URLs errored. Often the most valuable signal, because it catches partial failures that “completed” would hide.
A sensible default
Enable Crawl error and High error rate. Leave Crawl completed off unless you specifically want the audit trail — on an hourly warmer it produces two dozen messages a day, and channels people mute are worse than no alerts.
Setting up Slack
- 1
Create an incoming webhook in Slack
In your Slack workspace settings, add an Incoming Webhooks integration and choose the destination channel. Slack gives you a URL beginning
https://hooks.slack.com/services/…. - 2
Add the alert in Cache Rocket
On Account → Alerts, choose type Slack, give it a name, and paste the webhook URL.
- 3
Select events
Tick Crawl error and High error rate at minimum.
- 4
Save and test
Click Add alert, then start a warm run to confirm messages arrive.
Setting up Discord
In Discord, open Server Settings → Integrations → Webhooks, create a webhook, choose a channel, and copy its URL. Add it in Cache Rocket with type Discord.
Generic webhooks
Choose Generic webhook and give any HTTPS endpoint you control. Cache Rocket posts the event to it, and what happens next is up to you:
- Forward into PagerDuty or another on-call system.
- Open a ticket automatically for repeated failures.
- Trigger a retry or a fallback purge in your own automation.
- Log events into your own monitoring stack alongside everything else.
Careful
Your endpoint should respond quickly and not require authentication headers Cache Rocket cannot send. If it is slow or unreachable, notifications may not be delivered.
Choosing where alerts go
Route alerts to a channel someone actually reads. A few patterns that work:
| Setup | Routing |
|---|---|
| Solo operator | One Slack or Discord channel with crawl error and high error rate. |
| Agency | One alert endpoint per client workspace, posting into that client's channel, so failures are visible to the right team. |
| Team with on-call | A generic webhook into your incident tool for errors, plus a low-priority Slack channel for completions. |
Deploy and CI triggers
The alerts page also shows how to trigger warming from outside Cache Rocket — after a deploy, call triggerWarm with your API keys to start matching warmers, or warmUrls to priority-warm specific paths.
curl -X POST https://cacherocket.com/api/wordpress/triggerWarm \
-H 'Content-Type: application/json' \
-d '{"publicKey":"YOUR_KEY","secretKey":"YOUR_SECRET","hostname":"example.com"}'Full detail is in Deploy triggers.
Common problems
- Alerts are not arriving.
- Re-check the webhook URL for truncation, confirm at least one event is selected, and test the URL directly with curl to prove the destination accepts posts. Slack and Discord webhooks are also revoked when the integration is removed.
- I am getting too many alerts.
- Turn off Crawl completed first — it is almost always the noisy one. If crawl errors are frequent, that is a real problem to fix rather than silence; see Troubleshooting.
- Can I alert on a specific warmer only?
- Alert endpoints apply to the workspace they belong to. To separate signals per site, use separate workspaces with their own alert endpoints.
- What counts as a high error rate?
- Twenty-five percent or more of the URLs in a run returned errors.