Verify an integration
Verification should prove telemetry and interpretation, not merely package installation. Use a non-destructive test automation or a safe existing job.
Check credentials without exposing them
In the deployed environment, confirm only that the variable exists:
test -n "$CRONRADAR_API_KEY" && echo "CronRadar key is set" || echo "CronRadar key is missing"Do not run echo $CRONRADAR_API_KEY in shared logs or support transcripts.
Verify raw HTTP reachability
This creates or refreshes a dedicated verification monitor and records success. Run it only from an environment allowed to use the selected key:
curl --fail-with-body --silent --show-error \
--user "$CRONRADAR_API_KEY:" \
--get "https://cron.life/api/v1/ping/cronradar-verification" \
--data-urlencode "schedule=0 0 1 1 *"Expected response shape:
{
"status": "ok",
"monitor": "cronradar-verification",
"pingedAt": "2026-07-21T12:00:00Z",
"warning": null
}The timestamp will differ. HTTP 200 proves authentication, outbound HTTPS, registration, and ingestion. Delete or pause the verification monitor after the test if it is not a real recurring automation.
Verify framework discovery
These steps apply to an available framework SDK. Manual HTTP setup does not discover jobs: instead, run the actual job with its configured check-in, then confirm its schedule and successful execution in the matching CronRadar application.
- Deploy or restart the scheduler host after adding the integration.
- Open the matching application in CronRadar.
- Confirm a real recurring job appears with the scheduler's current cron expression.
- Run that job through the scheduler.
- Confirm a terminal result appears. A
startevent alone is still in progress.
Do not call the raw verification endpoint with the same key as a framework-discovered job; that can hide a discovery or lifecycle wiring problem.
Choose where alerts go
Open the application's Alerts tab and choose the delivery channels. If the workspace manages notifications, follow the link to its settings. Check the destination and the recipient preferences for this application.
For Slack, invite CronRadar to the public channel before selecting it. The Slack connection's test action can confirm that the selected channel receives a message. It does not prove that a scheduled-job failure was detected.
Record delivery as unverified until the intended recipient confirms an alert or channel test. When a real incident occurs, confirm the alert arrives and that a later successful run records recovery. If you need to exercise failure handling beforehand, use a harmless job in a separate test application and an agreed test destination. Do not deliberately fail a production job.
Open an alert from email
An incident email can include a link that opens a read-only summary for 24 hours without signing in. The summary shows the application and job names, the general cause, incident status, start time, and recovery time. It does not share logs, detailed error messages, credentials, notification recipients, or account controls.
This link does not sign anyone into your account. To investigate full run details, acknowledge the incident, or change settings, use the normal sign-in path and your account's permissions. Opening the summary does not acknowledge the incident or use up the link, so an email scanner cannot consume it before you open it.
Anyone who receives the email or link can read that summary until the link expires or is revoked. Job and application names may themselves be sensitive. Share only with the people who need that information. If the link has expired or been revoked, sign in normally or ask a workspace administrator for a new sharing link.
Share an incident deliberately
Open the incident's sharing controls from its alert history and review What the recipient can see. A workspace administrator can choose 1 hour, 24 hours, or 7 days, then select Create sharing link and copy it. Other workspace members can view the preview but need an administrator to create or revoke links.
The same controls list recent shared and alert-email links. Revoke an individual link when access is no longer needed, or select Revoke all active links to close every active link for that incident, including email links and older links outside the displayed list. Revocation prevents future access; it cannot remove information a recipient has already copied.
For an incident you are authorized to share, open its link in a signed-out browser, confirm that only the previewed fields appear, then revoke the link when you no longer need it. Confirm that the revoked link no longer opens the summary.
Keep alert mail useful
For an unresolved incident, CronRadar sends the first alert, at most one reminder every 24 hours, and a recovery message when a successful run resolves it. Acknowledge the incident in the console to stop further reminders. Acknowledgment does not stop monitoring or prevent recovery from being recorded. The reminder limit applies per incident; separate job failures can still produce separate alerts.
In an application's Alerts tab, choose delivery channels and review Application Notification Preferences. If notifications are managed by the workspace, use the linked workspace notification settings. Your alert emails lets you choose which applications reach your own inbox. Administrators can manage other members' recipient preferences.
Weekly reliability summaries are a separate opt-in preference and are off by default. Turning off application alert emails does not turn off necessary sign-in links, invitations, or account-change messages. Test your selected alert channel after changing the route or recipient settings.
Check your plan and bill
Open Billing in the console header on desktop or mobile to see your plan, active monitors by schedule class, and billing options. It is also available under Account → Billing. New accounts start on Free with 10 monitors and no credit card. There are no free trials.
Active monitors are non-paused, non-drill jobs across the billing owner's workspaces, including development and staging. Free includes 10. To go beyond 10, add a card once for Pay as you grow; there are no quantities or capacity to choose. The first 10 active monitors stay free, fastest schedules first. Each further monitor costs a flat monthly price by schedule: $2 Fast (under 5 minutes, or an unrecognized schedule), $1 Frequent (5–59 minutes), or $0.50 Standard (hourly and slower). Stripe bills monthly, after the month ends, on the month's peak count in each class, so pausing jobs before month end does not lower that month's bill. Runs, pings, retries, and API requests never change the bill. Optionally set a monthly budget in Billing (no limit by default): a new monitor, including a discovered job, that would push the month's bill over it stays paused as "budget reached" while existing monitors keep running. On Free, a discovered job beyond the 10-monitor limit is paused and unprotected until you pause another job or add a card. Free includes 30-day run and 90-day alert history; Grow includes 90/180 days. Upgrades cannot restore deleted history; effective downgrades apply shorter windows at the next cleanup. Pay as you grow has no monitor limit and no minimum. For custom contractual or procurement requirements, contact CronRadar.