A scheduled request failed overnight, and the fastest-looking fix is usually the riskiest one: change credentials, cadence, and retries at once, then wait. This guide uses Crontap MCP to identify the exact schedule, inspect retained history, classify the failing layer, and make one bounded correction. The assistant can organize evidence, but it can only report fields the tools expose. Request headers, bodies, and application logs are outside schedule history.
Before you start
- Connect through a client listed on the Crontap MCP hub and start with reads only.
- Have access to the destination service's runtime logs and, ideally, a request or business identifier.
- Do not paste API tokens, cookies, request bodies, or heartbeat ping URLs into the debugging prompt.
- Verified against the Crontap MCP guide and public API documentation on 2026-09-15.
Collect the exact schedule and history
Step 1
List before selecting
Call list_schedules and identify the candidate by label, destination host,
cadence, timezone, and status. If two entries look similar, stop and ask which
ID owns the failed workload. Do not update, pause, or delete by label alone.
Use only read-only Crontap MCP tools. List schedules that could match my failed catalog refresh. Show each candidate's ID, label, URL host, method, cadence, timezone, and status. Do not retrieve history or change anything until I choose an ID.Step 2
Retrieve the chosen ID
Call get_schedule with the selected opaque ID. Confirm that its URL, method,
interval, timezone, and current status match the workload. List and get output
does not include request headers or body, so do not infer their names or
values from the response.
Step 3
Read a bounded history page
Call get_schedule_history with the ID and a small limit such as 10. The safe
result can include id, startedAt, durationMs, statusCode, ok,
statusText, runId, attempt, a derived failureKind, and nextCursor.
Use the cursor only if an older page is genuinely needed.
For schedule ID SCHEDULE_ID, retrieve its saved non-secret configuration, then get the 10 newest history entries. Group failures by statusCode, statusText, failureKind, and attempt. Keep the schedule unchanged and do not claim access to headers, body, response content, or application logs.Classify the failing layer
Use history as a boundary marker, not a complete packet trace.
| Evidence | Safest conclusion | Next check |
|---|---|---|
| No row after the expected run | No recorded attempt at that expected time | Status, cadence, timezone, and exact ID |
400, 404, or 422 | Destination returned a client error | Route, method, payload contract in app logs |
401 or 403 | Destination rejected authorization | Secret configuration outside chat |
429 | Destination rate-limited the request | Endpoint limits and retry policy |
500 through 599 | Destination returned a server error | Runtime logs using time or runId |
ok=false without statusCode | Transport path failed before an HTTP response | DNS, TLS, connection, or timeout evidence elsewhere |
2xx with missing business output | HTTP exchange succeeded, application outcome unproved | App logs, queue, database, or provider record |
The sanitizer derives failureKind as client_error for 4xx, rate_limited for 429, server_error for 5xx, and transport_error when ok=false without one of those statuses. It does not expose a lower-level network exception. Avoid turning transport_error into a confident DNS diagnosis.
Step 4
Correlate one failed run
Pick one startedAt and runId, then search the destination logs around that
time. Confirm whether the route was reached, which validation failed, and
whether downstream work began. Record a business outcome such as imported
version or message ID without copying private payloads into the prompt.
Step 5
Make one bounded correction
Fix only the layer supported by evidence. A wrong path justifies a URL update. A paused resource justifies resume after review. A rejected secret justifies replacing it on the Crontap schedule page. Retrieve the same ID after any approved change and compare its next run.
Using the history and the application-log summary I provide, classify the failure as schedule state, transport, endpoint route or status, authentication, or business logic. State which observed field supports the classification. Propose one smallest next check, but do not modify the schedule.What production history actually returns
A read-only production check on 2026-09-15 listed schedules, selected one disabled schedule by ID, and requested three history entries. Each row exposed id, startedAt, ok, statusCode, statusText, durationMs, and attempt; the page also returned nextCursor. The observed failures were HTTP 400 responses. No request headers, request body, response body, or secret value appeared.
That check verifies the guide's field boundary, not the health of every schedule. It also shows why a 400 is an endpoint response: the scheduler recorded a completed HTTP exchange and its duration.
Verify the fix without overstating it
After the next scheduled attempt, read history again and compare the newest row. If the status changes from 401 to 2xx, destination authentication now accepts the request. Then verify the application's own output. A 2xx does not prove an import completed, a queue drained, or an email arrived.
For a status or cadence correction, retrieve the schedule and confirm the saved field plus next run. There is no MCP run-now tool, so do not ask the assistant to force an immediate schedule execution. Use a separately controlled endpoint test or wait for the next safe occurrence.
Troubleshooting
The assistant asks for the Authorization value
Do not provide it. MCP history cannot validate the value. Inspect or replace the header on the Crontap schedule page, then correlate the next status.
A 404 is described as a scheduler outage
A 404 is an HTTP response from the destination. Verify the production hostname, deployed path, and method.
There is no history at the expected time
Confirm the schedule is active, retrieve its timezone and interval, and calculate which UTC instant the local-time occurrence maps to.
Attempts have mixed statuses
Group by runId and attempt before concluding separate incidents. A retry sequence can contain an initial 5xx and a later success.
The change appears to work but data is stale
Inspect the route's downstream work. The handler may return before a queue completes or may suppress an internal error.
Next steps
- Build a reviewed request with Schedule API calls with an AI assistant.
- Check local-time assumptions with Timezone-safe recurring jobs.
- Follow the broader cron troubleshooting decision tree.
Ready to inspect your schedule safely? Free forever tier. No credit card. Create your Crontap account →
Verified against current Crontap MCP and public API contracts on 2026-09-15. Sources: Crontap MCP guide and Crontap public API.
FAQ
Failed HTTP cron job questions
- What fields can an agent see in schedule history?
- History exposes id, startedAt, durationMs, statusCode, ok, statusText, runId, attempt, a derived failureKind, and an optional pagination cursor when present.
- Can schedule history reveal request headers or bodies?
- No. Crontap MCP omits request headers and bodies from schedule and history output. Inspect or replace sensitive values only on the schedule page.
- How do I tell a scheduler failure from an endpoint failure?
- A history row means an attempt was recorded. A 4xx or 5xx is an endpoint response, while transport evidence without a status points to DNS, TLS, connection, timeout, or another network path.
- Why can a successful HTTP status still hide a broken job?
- The route may return success before work finishes or may perform no useful change. Correlate run time or runId with application logs and business output.