Update to Render

{
  "name": "render-cron-jobs",
  "description": "Configures and troubleshoots scheduled tasks on Render using cron job services. Use when the user needs to run something on a schedule, write a cron expression, set up a periodic job, migrate from Heroku Scheduler, choose between cron jobs and background workers, or fix a cron that isn't firing. Trigger terms: cron job, scheduled task, periodic job, cron expression, schedule, run every, timer, Heroku Scheduler migration.",
  "included_files": [
    {
      "relative_path": "references/cron-patterns.md",
      "size_in_bytes": 2674
    },
    {
      "relative_path": "references/migration-from-scheduler.md",
      "size_in_bytes": 2749
    }
  ],
  "skill_md_contents": "---\nname: render-cron-jobs\ndescription: >-\n  Configures and troubleshoots scheduled tasks on Render using cron job\n  services. Use when the user needs to run something on a schedule, write a\n  cron expression, set up a periodic job, migrate from Heroku Scheduler,\n  choose between cron jobs and background workers, or fix a cron that isn't\n  firing.\n  Trigger terms: cron job, scheduled task, periodic job, cron expression,\n  schedule, run every, timer, Heroku Scheduler migration.\nlicense: MIT\ncompatibility: Render cron job services\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: compute\n---\n\n# Render Cron Jobs\n\nThis skill covers **Cron Job** services on Render: how schedules run, what the platform guarantees, and how they differ from workers and workflows. Pair it with Blueprint and deploy skills when authoring `render.yaml` or Dashboard settings.\n\n## When to Use\n\n- **Scheduled** work that **starts on a cron**, runs a command, and **exits** when finished\n- Choosing between **cron**, **background worker**, or **workflow** for periodic or long-running jobs\n- **Blueprint** fields for `type: cron`, `schedule`, and commands\n- **Constraints**: no disk, single concurrent run, 12-hour max duration, private-network **outbound** only\n- **UTC** scheduling pitfalls (expressions are **not** local time)\n\nExpression cheat sheets, framework `startCommand` examples, and Heroku Scheduler migration mapping live under `references/`.\n\n## Configuration\n\n- **Schedule**: a **cron expression evaluated in UTC**, not the team’s local timezone. All times in the Dashboard and Blueprints are UTC.\n- **Command**: any valid **Linux shell command** or **bash script** path. The process must **exit** when work is done—**billing is based on run duration** (prorated by the second).\n- **Source**:\n  - **Git repository** — Render **builds on push** (same deploy model as other repo-backed services); the built artifact runs on each scheduled invocation.\n  - **Prebuilt Docker image** — the image is **pulled before each run** and is **not retained between runs** (no warm cache of the image layer set across invocations in the same way as a long-lived service).\n\n## Constraints\n\n- **No persistent disk** — cron job services **cannot** provision or attach Render persistent disks; plan for object storage or databases instead.\n- **Single-run guarantee** — at most **one active run** per cron service at a time. A new scheduled tick does not start a second overlapping instance.\n- **Maximum run length**: **12 hours** per invocation.\n- **Pricing**: **$1/month minimum** per cron job service; usage is **prorated by the second** beyond plan/minimum rules that apply to your account.\n- **Private network**: cron jobs **can send** traffic **to** other services on the private network; they **cannot receive** inbound private-network connections (no internal hostname for accepting traffic from other services).\n\n## Execution Behavior\n\n- **Manual “Trigger Run”** while a run is **active**: Render **cancels** the active run, then **starts** a new one.\n- **New Git build / deploy** does **not** affect a run already **in progress**—the in-flight process keeps using the revision it started with until it exits.\n- **Docker-based crons**: the image is **pulled fresh for each run**; do not assume layer or image reuse across invocations like a continuously running container.\n- **UTC everywhere**: cron expressions and “midnight” in docs mean **UTC**. A common mistake is copying a local-time schedule into the expression without converting to UTC.\n\n## Cron vs Worker vs Workflow\n\n| Need | Use | Why |\n|------|-----|-----|\n| Periodic task **under 12h** | **Cron Job** | Scheduled, simple, exits when done |\n| **Continuous** job processing | **Background Worker** | Always running, polls a queue |\n| Periodic but **over 12h** | **Background Worker** | No 12h cron run ceiling |\n| **Scheduled parallel** compute | **Cron Job + Workflow** | Cron triggers workflow runs on a schedule; workflows fan out or orchestrate parallel steps |\n\n## Blueprint Configuration\n\nCron services use **`type: cron`** with a **`schedule`** and the usual build/start and env wiring:\n\n```yaml\nservices:\n  - type: cron\n    name: nightly-cleanup\n    schedule: \"0 * * * *\" # hourly at minute 0 — must be quoted in YAML\n    buildCommand: pip install -r requirements.txt\n    startCommand: python cleanup.py\n    envVars:\n      - key: DATABASE_URL\n        fromDatabase:\n          name: my-db\n          property: connectionString\n```\n\n- **`schedule`**: standard five-field cron (`minute hour day-of-month month day-of-week`), **UTC**.\n- **`buildCommand`** / **`startCommand`**: same roles as other non-Docker services; Docker images use image + start command as configured for image-backed crons.\n- **`envVars`**: same patterns as web services and workers (secrets, linked databases, etc.).\n\n**YAML note**: the `schedule` value **must be quoted** so characters like `*` are not parsed as YAML aliases or flow syntax.\n\n## Common Patterns\n\n- **Database cleanup** — archive or delete stale rows on a schedule\n- **Report generation** — build CSV/PDF and upload to object storage or email\n- **External API sync** — pull or push batches on an interval\n- **Cache warming** — hit endpoints or rebuild caches before peak traffic\n- **Scheduled emails** — digest or reminder sends driven by cron + mail/API\n\n## References\n\n| Topic | File |\n|--------|------|\n| Expression examples, framework commands, errors, env vars | `references/cron-patterns.md` |\n| Heroku Scheduler → Render mapping, blueprint example | `references/migration-from-scheduler.md` |\n\n## Related Skills\n\n- **render-deploy** — First-time deploy, service creation, Dashboard flow\n- **render-blueprints** — Full `render.yaml` schema, previews, common mistakes\n- **render-background-workers** — Long-lived processes, queues, no 12h cap\n- **render-workflows** — Orchestrated and parallel jobs, often triggered on a schedule from cron\n"
}