Docs

Runrail Public Beta Quickstart

Runrail schedules recurring Base Sepolia contract calls and keeps each job's readiness, attempts, retries, confirmation, receipt, transaction hash, and explorer link together. Use the App for an interactive workflow or the API from your own tools and agents. Both interfaces use the same Runrail workspace.

1. Sign In To The App

Open https://app.runrail.app, connect your browser wallet, and sign the message Runrail requests. This verifies control of the address and starts a secure browser session.

Your sign-in wallet identifies your Runrail workspace. It does not fund jobs or sign Runrail execution transactions.

2. Set Up The Execution Wallet

Request Execution-wallet setup in the App. Runrail assigns one dedicated Base Sepolia Execution wallet to your workspace. When its address is ready, fund it with Base Sepolia test ETH.

  • Your sign-in wallet identifies you.
  • Your Execution wallet submits scheduled transactions.
  • Runrail operates the Execution-wallet key; you do not receive its private key.
  • You provide the Base Sepolia test ETH used for gas.

Do not send production funds or valuable assets to the Execution wallet.

3. Create A Recurring Job

Create a job with these five fields:

  • name
  • a nonzero EVM target address
  • hexadecimal calldata, from empty 0x up to 8,192 decoded bytes
  • startAt, from 2 minutes to 365 days in the future
  • intervalSec, from 15 minutes to 365 days

Runrail fixes the network to Base Sepolia, chain ID 84532, and transaction value to 0. A new job remains inactive until you activate it; creation does not execute it immediately.

4. Check Readiness And Activate

Readiness is ready, not_ready, or unknown. It reflects the current Execution-wallet state and funding, target code, simulation result, gas policy, schedule, quotas, and safety controls.

Resolve any reported issue before activating the job. Runrail rechecks readiness when you activate or resume and before scheduled work. unknown fails safely and does not admit new work. Readiness is a current check, not a guarantee that a later transaction will succeed.

5. Follow Scheduled Execution

An active job runs on future scheduled slots. There is no public run-now action. Each slot receives one initial attempt and, when the failure is retryable, up to two retries.

Execution history shows whether work used the primary or fallback path and whether it is waiting, submitted, confirming, retrying, confirmed, reverted, exhausted, skipped by policy, or stopped by a failed precondition.

Submission alone is not success. A successful execution reaches confirmation and includes a terminal receipt. Transaction hashes and Base Sepolia explorer links help you inspect the on-chain result.

6. Manage The Job

  • Pause a job to stop future scheduled work.
  • Resume it after Runrail completes a fresh readiness check. It continues at a future slot; missed slots are not backfilled.
  • Archive it when you no longer need it. Archive is irreversible and preserves execution history.

Already submitted transactions continue to reconciliation even if the job is later paused, archived, or affected by a safety control.

7. Use The API When You Need Automation

In the App's API Access area, create a bearer credential, copy it immediately, and store it as a secret. The plaintext is shown once and cannot be recovered. You can list non-secret credential metadata and revoke a credential from the App.

Use that credential only with https://api.runrail.app/v1. Jobs created through the API appear in the App, and jobs created in the App appear through the API. Signing out of the App does not revoke API credentials.

See Runrail API Usage for request examples.

Guided Pilot

Guided Pilot is a secondary manual path for a custom use case that does not fit Public Beta's Base Sepolia, value=0, scheduling, or safety limits. It is not required for ordinary App or API access.

Continue with App Usage, Limits and Safety, or Runrail API Usage.

Back to docs index