Put recurring work on a schedule. Review what comes back.

Sweep dependencies every Monday. Re-sync docs nightly. Describe the job once in plain English; Echelar drafts the Automation — trigger, scope, checks, destination — and it stays disabled until a person turns it on. When the work changes code, it comes back as a pull request.

  1. Described in a Session
  2. Drafted
  3. Validated
  4. Enabled by a person
  5. Monday’s pull request
Put one chore on a scheduleWatch the demonstration

Thirty minutes with the founder. One repository, read-only, is all it needs.

The maintenance nobody owns

Dependencies rot until the quarterly scramble

Not because the fix is hard. Because nobody owns Monday.

The cron job outlived its owner

It stopped quietly the week they left. Nothing was watching for it to.

Automating is its own project

Writing the glue takes longer than doing the chore.

Demonstration

Standing orders

One request in a Session. One disabled draft. One Monday pull request.

Describe the recurring job in a Session. Echelar drafts the schedule, scope, checks, and Reviewer handoff, and the draft stays disabled until an authorized person enables it. On Monday at 08:00 the Automation starts and comes back as pull request #88, waiting for review.

Demonstration — authored data · human review before enablement
Starts when visible

Sequence description

  1. A teammate asks for a weekday Automation that repairs the slowest checkout-api spec.
  2. Echelar loads the repository architecture, test conventions, and required checks.
  3. The Session inspects recent test timing and identifies the slowest stable spec.
  4. Echelar drafts the schedule, scope, pull-request delivery, and Reviewer handoff.
  5. The Automation definition is validated against repository capabilities and approval rules.
  6. A disabled Automation draft appears for human review.
  7. A person on the team reviews the definition and explicitly selects Enable Automation.
  8. The enabled Automation is attributed to Mouna and waits for its next scheduled start.
  9. Monday 08:00 arrives and the schedule starts the Automation.
  10. A Session repairs the slowest spec in acme/checkout-api and checks the suite.
  11. Pull request 88 arrives for review, and the audit record ties it to the Automation, its version, and the Monday start.

Demonstration on a fictional Acme repository — authored data.

How a scheduled Automation works

A definition, not a script
The Automation is a versioned definition your team can read, diff, and roll back. No glue code to own.
Validated before it is live
Every draft is checked against the repository's capabilities and approval rules. Before you enable it, we can dry-run it with you against a real recorded event and show exactly why it would or would not fire.
Disabled until a person enables it
Every draft lands off. Enabling is a human action, recorded with the person's name.
Code changes come back as pull requests
When the job changes code, the result is a focused pull request on the repository it belongs to. Nothing merges.

Repository maintenance, before and after Echelar

Without EchelarWith Echelar
Dependency updatesA quarterly scramble.A focused pull request every Monday, waiting for review.
Versus Dependabot or RenovateDependency updates only.Any recurring job you can describe, with your repository's conventions loaded and a person's enablement on record.
When it fails silentlyNobody notices until something breaks.Every fire leaves an audit record with a match trace and the prompt it sent.
Changing the scheduleFind the cron, find the owner, redeploy.A new version, kept alongside the old ones for rollback.

Same job, on your repository.

Put one chore on a schedule

Scheduled Automations FAQ

How is this different from Dependabot or Renovate?

Those update versions. An Automation covers any recurring job you can describe — a dependency sweep, a flaky-spec repair, a docs re-sync — with your repository's conventions loaded, validated before it is live, and a person's enablement on record.

It fires at 08:00 with nobody watching. What can it touch?

A branch in an isolated sandbox, and the pull request it opens from it. Scope is the repositories you set; nothing else.

How many pull requests will this create?

At most one focused pull request per fire, and only when the job changes code, scoped by the schedule and repositories you set.

Can one Automation cover several repositories?

Yes. Scope can span repositories; each result still arrives as a pull request on its own repository.

What does it cost?

Echelar is launching now. Early teams work directly with the founder and agree pricing together.

Bring the real one.

Bring the Monday dependency sweep or the nightly docs re-sync nobody owns. We draft it live and dry-run it with you against a real recorded event, so you read exactly what it would have done.

Put one chore on a schedule

Not ready to book? Read how access and approvals work first.

One team of agents. Four more jobs.