crontap-replace-vercel-cron

Replace Vercel Cron

Keep Vercel as the runtime and move only the clock. Crontap calls the deployed route over HTTPS.

Prerequisites

Before using the required tools, check whether they are available. If any are missing, stop and offer the user exactly two choices:

1. Connect Crontap MCP at https://mcp.crontap.com/mcp. MCP access works on every Crontap tier.
2. Configure $CRONTAP_CLIENT_ID and $CRONTAP_API_KEY for the raw API. Raw API access requires Ultra.

Do not silently choose a path or continue until the user selects one.

• Read the existing vercel.json cron path and expression.
• Confirm the production hostname and route method.
• Protect the route with a dedicated secret header.
• Make the handler idempotent before cutover.

Cutover workflow

1. Add or verify route authentication in the Vercel application.
2. Test the protected production route with a controlled request.
3. Choose a cutover time and explain the brief overlap or gap risk.
4. Remove or disable the vercel.json schedule.
5. Create the matching Crontap schedule immediately.
6. Verify the resolved timezone, next runs, and first history entry.
7. Keep a rollback plan: pause Crontap, restore the Vercel cron, then deploy.

Do not leave both clocks enabled. Two schedulers can create duplicate side effects even when both are operating correctly.

MCP examples

Create the replacement:

{
  "tool": "create_schedule",
  "arguments": {
    "url": "https://app.example.com/api/cron/daily-report",
    "cron": "0 9 * * 1-5",
    "timezone": "UTC",
    "method": "GET",
    "headers": {
      "Authorization": "Bearer <secret-from-secure-store>"
    },
    "label": "Vercel daily report"
  }
}

Pause for rollback or maintenance:

{
  "tool": "pause_schedule",
  "arguments": {
    "scheduleId": "<schedule-id>"
  }
}

Resume the same configuration:

{
  "tool": "resume_schedule",
  "arguments": {
    "scheduleId": "<schedule-id>"
  }
}

Confirm the selected ID before pause or resume.

Protected route pattern

Compare the request authorization header with a server-only environment variable. Return 401 before performing work when it does not match. Do not use a secret in the query string or route path.

If the route queues work, persist the logical schedule period as an idempotency key before enqueueing. Return success only after the queue accepts the job.

REST fallback

REST creation requires Ultra API access:

curl --fail-with-body https://api.crontap.com/v1/schedule \
  -X POST \
  -H "ClientId: $CRONTAP_CLIENT_ID" \
  -H "ApiKey: $CRONTAP_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "url": "https://app.example.com/api/cron/daily-report",
    "interval": "0 9 * * 1-5",
    "timezone": "UTC",
    "verb": "GET",
    "headers": {
      "Authorization": "Bearer <secret-from-secure-store>"
    },
    "label": "Vercel daily report"
  }'

Use MCP for non-Ultra accounts.

Verification

• Confirm the old Vercel schedule is absent from the deployed configuration.
• Confirm only one Crontap schedule targets the route.
• Verify a 401 without the secret and success with the secret.
• Inspect the first real run and the application-level side effect.

Safety and plan limits

• Never paste the production route secret into the skill, repository, or chat.
• Pause before restoring the old scheduler during rollback.
• Preserve the original cadence's UTC semantics unless the user explicitly chooses a local IANA timezone.
• On a cap or cadence error, present the returned four-option ladder and smallest viable option.

Troubleshooting

• A Vercel 401 means the configured schedule header and route secret differ.
• A 404 often means the route is not deployed on the hostname being called.
• Duplicate output means both clocks are active or endpoint idempotency failed.
• A timeout may require durable queueing instead of long synchronous work.

References

• Crontap Agent Skills catalogue
• Vercel Cron limits and alternatives
• Vercel Cron alternative
• Cron troubleshooting
• Cron job monitoring