Best Practices

Use descriptive check names

Name checks after what they monitor, not how they run. Nightly DB Backup is better than Cron Job #3. When you get an alert at 3 AM, a clear name saves time.

Set appropriate grace periods

Don't set the grace period too tight — account for network latency, server load, and normal job duration variance. A grace period that's 2x your typical job duration is a good starting point.

Use start + success + fail signals

Using all three signal types gives you the most visibility:

• Start — tells you the job began, and enables run duration tracking.
• Success — confirms successful completion.
• Fail — triggers an immediate alert without waiting for the grace period.

Always use --retry with curl

Network hiccups happen. Adding --retry 3 makes your pings resilient to momentary connectivity issues without adding complexity.

Don't let ping failures break your job

The monitoring call should never cause your actual task to fail. Use timeout flags (--max-time 10 with curl) and handle errors gracefully. Your backup is more important than the ping.

Monitor the scheduler itself

If you use a central scheduler (like Laravel's schedule:run or a cron daemon), create a dedicated check that pings every minute. If the scheduler itself stops, all your other checks will eventually alert — but a dedicated "scheduler heartbeat" catches it immediately.

Use tags to organize checks

Group related checks with tags like production, staging, backups, or payments. Tags make it easy to filter your dashboard and create aggregate status badges.

Pause checks during maintenance

Before a planned deployment or maintenance window, pause the affected checks from your dashboard. This prevents false alerts while you work. Don't forget to resume them afterward.