CronRunner User Guide

Scheduled HTTP requests — cron-as-a-service with retry logic, response logging, and failure alerting.

1. Enable CronRunner in the Products page

2. Navigate to run.microgemlabs.ai

3. Click + New Job to schedule your first HTTP request

CronRunner makes HTTP requests on a schedule. Instead of running cron on your own server, you define "hit this URL every 5 minutes with these headers and this body" and CronRunner executes it reliably with retry logic, response logging, and failure alerting.

• Trigger a cache warm endpoint every 15 minutes
• Call an analytics sync API every 6 hours
• Ping a health check endpoint every 5 minutes
• Run a scheduled data export via webhook
• Trigger a cleanup job on a serverless function

Target

• URL — The HTTP endpoint to call (must be a valid URL starting with http:// or https://)
• Method — GET, POST, PUT, PATCH, or DELETE
• Headers — JSON object for custom headers (Authorization, Content-Type, etc.)
• Body — Request body for POST, PUT, PATCH methods
• Content-Type — Body content type (default: application/json)

Schedule

Cron expression in standard 5-field format: minute hour day-of-month month day-of-week

Behavior

• Timeout — Seconds before the request is aborted (5-120, default: 30)
• Retries — Number of retry attempts on failure (0-3, default: 0)
• Retry Delay — Seconds between retries (10-600, default: 60)
• Expected Status — Comma-separated HTTP status codes that indicate success (default: 200). The job is marked failed if the response status is not in this list.
• Alert on Failure — Whether to fire an on-call alert on repeated failures (default: yes)

1. Dispatcher runs every minute, finds jobs where nextRunAt <= now

2. Each job is executed independently (up to 30 concurrent)

3. CronRunner sends the HTTP request with your configured method, headers, body, and timeout

4. If the response status matches expectedStatus, the execution is marked success

5. If it doesn't match, or the request times out/errors, it's marked failed

6. On failure with retries configured, CronRunner waits retryDelay seconds and retries

7. After all attempts, it records the result and computes the next run time

CronRunner fires an on-call alert after 2 or more consecutive failures (not on a single failure). This prevents noise from transient network issues. The alert escalates to critical severity after 5+ consecutive failures.

When the job succeeds again after failures, the on-call alert is automatically resolved.

Jobs List

Shows all scheduled jobs with:

• Status badge (success/failed/paused/new)
• Name, cron expression, method + URL
• Execution sparkline — last 20 runs as green/red/amber bars for at-a-glance health
• Next run countdown
• Last run time
• Consecutive failure warning banner (2+ failures)

Job Detail

• Stats cards — Total runs, success rate %, average duration, consecutive failures
• Configuration display — URL, method, timeout, expected status, retry settings, headers (pretty JSON), body (dark code block)
• Execution history table — Timestamp, status badge, HTTP code, duration, attempt number, error text

• Run Now — Trigger an immediate execution outside the schedule. Useful for testing a new job or re-running after a fix.
• Pause — Stop scheduled executions. The job won't run until resumed.
• Resume — Re-enable scheduling. The next run time is recalculated from the cron expression.
• Delete — Remove the job and all execution history.

They're complementary. Use CronRunner when you need a reliable scheduler, and CronKeeper when you already have cron but want to verify it's running.

CronRunner identifies itself with a User-Agent: CronRunner/1.0 (https://run.microgemlabs.ai) header. Your server can use this to distinguish scheduled requests from normal traffic.

Failure alerts route through the shared MicroGemLabs escalation policy. The on-call engineer receives the job name, URL, error message, HTTP status, and consecutive failure count in the alert notification.

MicroGemAI tracks execution time for each successful job run against a 7-day rolling baseline. If a job that normally completes in 2 seconds starts taking 15 seconds, an anomaly alert fires — even though the job isn't technically failing. This catches degrading endpoints before they start timing out.

Configure sensitivity from the Anomalies page (Ops → Anomalies).

Suppress CronRunner failure alerts during planned maintenance (Ops → Maintenance). Jobs continue executing on schedule and results are logged, but consecutive failure counting won't trigger on-call alerts. Execution time data during windows is excluded from anomaly baselines.

MicroGemAI extrapolates execution time trends: "Analytics sync job slowing at 500ms/day. Will exceed 30s timeout in 6 days." Uses linear regression over 48 hours of hourly-aggregated execution times. Enable in Anomalies → Detection Settings. Requires R² > 0.3 and positive slope to generate predictions.

Define automated responses to job failures (Skills → Runbook (/agent/skills?type=runbook)). Example: create a "Restart Analytics Worker" template that POSTs to your orchestration API when CronRunner reports 3+ consecutive failures for a specific job. Set a trigger pattern and trust level. Every execution is audited with full HTTP request/response capture.

When persistent job failure patterns resolve, MicroGemAI auto-generates a postmortem with the failure timeline, error messages, what changed (cross-product correlation), and prioritized action items. Review and publish at Ops → Postmortems.