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.
- Open a site's Monitors tab and click Add API monitor.
- Set the method (GET, POST, etc.), the URL, and optional headers/body.
- Set expected status codes — the check fails if the response doesn't match.
- 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.
- From the Monitors tab, click Add port monitor.
- Set a label, the host, and the port number.
- Choose the expected state — open or closed.
- 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:
- Click Add monitor and give it a name.
- Define the schedule either as a cron expression (e.g.
0 2 * * *) or a simple frequency in minutes. - Set a timezone and how many missed runs to tolerate before alerting.
- 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.