Troubleshoot by observable symptom

Start with what you can see. Every check below is safe to copy and avoids printing the API key.

The job does not appear after deployment

Confirm the key exists in the scheduler process, not only in your shell:

test -n "$CRONRADAR_API_KEY" && echo "CronRadar key is set" || echo "CronRadar key is missing"

Then confirm outbound HTTPS and authentication with the raw verification command. Check the matching guide's current SDK availability. For manual HTTP setup, run the real job's check-in with its schedule; jobs are not discovered automatically. For an available framework SDK, inspect its discovery conditions and restart the process that owns the scheduler registry after registering the integration.

Logs show `401 Unauthorized`

The key is missing, malformed, revoked, or belongs to a different application. Keys begin with ck_app_ and plaintext is shown only when created or rotated. Create a replacement key, update the secret store, redeploy, verify, then revoke the old key.

Do not paste a key into a URL shown in logs or a support message. Use Basic authentication for manual diagnostics so the key stays out of the URL.

Logs show `404 MONITOR_NOT_FOUND`

A base SDK or raw HTTP call used a new key without a schedule. Pass the five-field schedule on the first heartbeat or lifecycle start call. Framework integrations should reconcile before execution; a framework 404 usually means startup reconciliation did not run or failed.

The monitor remains `pending`

The automation is registered, but no terminal execution result has arrived. Run the job through its scheduler. If the dashboard shows a start without completion, inspect the job host for a still-running process or missing execution hook. Do not mark onboarding complete from registration alone.

The dashboard schedule is wrong or stale

For an available framework SDK, follow its guide's supported reconciliation steps. For manual HTTP reporting, check the schedule configured on the monitor; restarting the scheduler does not synchronize it automatically. Verify that the expression represents the real job's schedule without changing its meaning. If runs are reported late at the same hour each day, or on days the job does not run, compare the expression with cron schedule syntax: CronRadar evaluates schedules in UTC and requires a date to match both day fields when both are restricted.

The job runs, but no lifecycle result appears

Confirm outbound access to https://cron.life and check SDK diagnostics. Short-lived scripts should await asynchronous SDK methods or use the synchronous API before process exit. Official SDKs intentionally do not throw when telemetry fails, so application success does not prove monitoring delivery.

An automation is `paused` after discovery

If it is marked plan-limited, discovery found more active automations than the plan protects. CronRadar records the automation but does not activate it or create an overage. Pause another automation or upgrade, then reconcile again. If it was paused because it disappeared, restore the recurring-job declaration and reconcile; automatic drift pauses resume without overriding a manual pause.

No alert notification arrives

Check the job's status and incident history first. A healthy run does not create a failure alert. In the application's Alerts tab, confirm that the channel is enabled, its destination is current, and the intended recipient has alert emails enabled for this application. Follow the workspace settings link if it manages delivery.

For Slack, confirm CronRadar has joined the selected public channel and use the connection's test action. A successful API response does not prove recipient delivery. Correct the destination or preferences before testing again; use a harmless job in a separate test application if you need to exercise failure handling.