Migration Guide
No 15-minute drift. No CI minutes. Proper failure alerting.
Look for workflow files with "on: schedule:" triggers in your .github/workflows/ directory.
# .github/workflows/cleanup.yml
on:
schedule:
- cron: "0 * * * *"
jobs:
cleanup:
steps:
- run: curl -X POST https://myapp.com/api/cleanupFor workflows that call an HTTP endpoint (via curl or actions/http-client), note the URL, method, and headers.
If your workflow runs application code directly, wrap it in an HTTP route on your deployed app.
// Express
app.post('/api/cleanup', authenticate, async (req, res) => {
await cleanupOldRecords();
res.json({ cleaned: true });
});Create a JustRun job for each workflow: same cron expression, HTTP endpoint URL, and any required auth headers. Use the CLI: npx @justrun/cli create.
In each workflow file, remove the "schedule" trigger or add an "if: false" condition to disable it. Keep the workflow for manual/event-triggered runs if needed.
# Disable schedule trigger, keep manual trigger
on:
workflow_dispatch: {} # keep this for manual runs
# schedule: disabledConfigure multi-phase alerts in JustRun — notify Slack immediately, page PagerDuty after 5 minutes.
During peak load, GitHub Actions schedule triggers can be delayed 15–60+ minutes. JustRun triggers within seconds of the scheduled time.
Yes — and you should. GitHub Actions is excellent for CI/CD. Just move the schedule triggers to JustRun, which is purpose-built for reliable scheduling.
Create an HTTP endpoint in your app that performs the action. For things that genuinely need repo access (commit, push), keep using GitHub Actions with a manual trigger or webhook.