API, port, ping, and cron monitors

Add extra monitor types beyond the automatic site checks — HTTP endpoint checks, TCP port checks, ICMP ping, and scheduled job monitoring.

Beyond the checks that run automatically once you add a site, a site's Monitors tab lets you add a few more monitor types for things a plain uptime check can't see.

API monitors

Check a specific HTTP endpoint on a schedule, separate from the site's main uptime check — useful for a health endpoint, an authenticated API route, or a webhook receiver.

  1. Open a site's Monitors tab and click Add API monitor.
  2. Set the method (GET, POST, etc.), the URL, and optional headers/body.
  3. Set expected status codes — the check fails if the response doesn't match.
  4. Choose a check interval.

Failures show up on the dashboard and can trigger an API monitor failing alert rule.

Port monitors

Check that a TCP port is open (or closed, if that's what you expect) — useful for database ports, SSH, or any non-HTTP service.

  1. From the Monitors tab, click Add port monitor.
  2. Set a label, the host, and the port number.
  3. Choose the expected state — open or closed.
  4. Choose a check interval.

Ping monitoring

A lighter-weight ICMP ping check, as an addition to the main HTTP uptime check. It's off by default — toggle it on from the site's Monitors tab. Once enabled it runs on the same check interval as the site's uptime check.

Cron monitors

Get alerted when a scheduled job doesn't run, not just when it fails while running. From a site's Cron monitors tab:

  1. Click Add monitor and give it a name.
  2. Define the schedule either as a cron expression (e.g. 0 2 * * *) or a simple frequency in minutes.
  3. Set a timezone and how many missed runs to tolerate before alerting.
  4. Save — DownCTL generates a unique ping URL for the monitor.

Have your job call that URL when it runs. If a ping doesn't arrive within the expected window, the monitor is marked overdue and can trigger a cron job failing alert rule.

Treat the ping token as a credential — there's no auth header on these endpoints, so anyone with the URL can ping the monitor. Keep it in .env or a config value pulled from the environment (as in the Laravel example below), not hardcoded directly in a script or committed to a public repo.

Laravel: if you have bluecapapps/downctl-laravel installed (see error tracking), chain ->cronMonitor() onto a scheduled task instead of calling the ping URL yourself:

use Illuminate\Support\Facades\Schedule;

Schedule::command('reports:daily')
    ->dailyAt('06:00')
    ->cronMonitor(config('downctl.monitors.reports_daily'));

This pings /started, /finished (with measured runtime), or /failed automatically depending on how the command exits. Run php artisan downctl:crons:sync to list every monitored task and confirm its ping URL.

Plain PHP: bluecapapps/downctl-php provides the same lifecycle without the scheduler integration:

$downctl->pingCronStarted('your-ping-token');

try {
    runImport();
    $downctl->pingCronFinished('your-ping-token', ['runtime' => 12.4]);
} catch (\Throwable $e) {
    $downctl->pingCronFailed('your-ping-token', ['failure_message' => $e->getMessage()]);
}

Anything else: call the ping URL directly — see the API reference for the full set of /started, /finished, and /failed variants, plus accepted metadata.

You can also create or update cron monitors in bulk from code instead of the UI — see cron monitor sync in the API reference.

Ready to be first
to know?

Add your first site in 30 seconds. Start your free trial today.

14-day free trial · No credit card required · Cancel anytime