Scheduled jobs and small automations that keep running

The workflow

1. Select a bounded automation with a clear owner, input and observable result. Write down its schedule, duplicate-handling rule, failure behavior and manual recovery step before asking the agent to code it.
2. Give the agent a specific prompt: Build a weekly account-review digest. Store account names, review dates and processing state in Postgres. Require login. Every Monday morning, run a scheduled job that finds reviews due in the next seven days and writes a digest record. Create an operator page showing the last successful run, included accounts, skipped rows and errors. Make reruns idempotent. Do not send email or call an external service.
3. Have the agent build a full app in the initialized folder. The pieces are an operator page, Postgres for source and run state, login for the owner, and the weekly scheduled job. Use the default share URL first. A custom domain is optional on Pro and does not make the automation more reliable.
4. Test the job with a fixed clock and a small dataset. Run it twice and confirm that the second execution does not create duplicate digest records. Introduce one invalid row and verify that the operator page shows the skip or error without hiding successful work.
5. Push and checkpoint the reviewed state, then restrict the share to the operator by password or invitation. Record the manual rerun and recovery instructions on the page where the result appears.
6. After the first scheduled execution, inspect the stored result rather than assuming that configuration means success. Let the agent read operator comments, fix the same workspace and publish a new checkpoint while preserving the app's address and history.

Setup

grain login
mkdir account-review-digest
cd account-review-digest
grain init
# Give the agent the scheduled-job prompt and test records.
grain push
grain checkpoint -m "weekly digest verified"
grain share --password <pw>
# Use invited-person sharing for named operators.

Download the Mac app before the CLI sequence. Use a full app because the job requires durable inputs, run records and an operator view. Postgres stores the account rows and execution state. Login and a restricted share protect the operator surface. The scheduled job runs weekly, while the page shows last success, included rows, skips and errors. Start with the default https://<slug>.share.rungrain.com address. Pro adds CNAME custom domains if a company URL is required. Verify the schedule, database mutations, idempotency, access boundary and visible failure path independently before depending on the automation.

What you get

• A scheduled job attached to a published app workspace rather than a script that exists only in the agent's terminal session.
• Postgres state for inputs, execution records and idempotency markers, all defined by the app the agent writes.
• An operator page with the last successful run, affected records, skipped work and errors visible at a lasting URL.
• Login plus public, password-protected or invited-person sharing choices, so the operator surface has an intentional audience.
• Reader comments that the agent can read when an operator reports a missing record, unclear status or recovery problem.
• Named checkpoints around verified behavior and ordinary artifact files that remain fetchable with grain pull.
• An optional Pro custom domain, while the scheduled job and default share address remain separate concerns.

Proof

Use a controlled run as proof. Insert three due accounts, one future account and one invalid row. Run the job at the planned boundary, reconcile the digest, then run it again and verify that no duplicates appear. Sign out and confirm the login boundary. Leave an operator comment and verify the agent can read it. Close the authoring session and inspect the next scheduled result from the same URL. Grain supports Postgres, login and scheduled jobs in app artifacts, and published artifacts stay published on the free tier. The job's correctness is still the responsibility of its code, test cases and human owner. A visible run record is evidence; the presence of a schedule alone is not.

Limits

• Every automation needs a named owner and manual recovery path. Do not create an unattended job whose failures no one is expected to inspect.
• Scheduled execution does not guarantee idempotency. Design a durable key or state transition and test repeated runs against the same input.
• External side effects such as sending mail, moving money or changing customer systems require their own credentials, rate-limit handling, audit and approval design. This example deliberately excludes them.
• Keep secrets out of the artifact files and page. Review the data and access requirements before storing sensitive records.
• The free tier includes one always-on workspace. More always-on workspaces, seats, shared spaces and custom domains are paid Pro capabilities.
• Grain is not an agent orchestrator or general production deployment platform. It does not schedule agent reasoning or replace a production operations stack.

Frequently asked questions