Ryker / Docs / Schedules and follow-ups

Schedules and follow-ups

Some work starts at a particular time, some starts when an event arrives, and some needs a pause before the next step. Ryker has schedules, rules, and follow-ups for these three cases.

Schedule a check

Ask in the conversation where you want the results. Include the job, time, and timezone:

@Ryker every weekday at 09:00 America/New_York, check production health and post the findings here.

Ryker shows the proposed schedule on a card. Check its timing and work before confirming. In Slack, a configured operator confirms; on GitHub, the confirmer needs write access to the repository. Nothing runs until confirmation.

A schedule can run once, on an interval from five minutes to a year, or daily, weekly, or monthly. It can have an end date. Ask in the original conversation to change what it does.

What happens at the scheduled time

Each run starts with fresh context and uses the conversation’s environment and Emisar policy. The schedule page says whether its runs may only inspect, change a repository, or perform operations that require approval in Emisar.

Two runs of the same schedule never overlap. If a run cannot start within 15 minutes of its scheduled time, Ryker records it as missed. The next run keeps its original time.

Under Automations › Schedules, or in Slack App Home, use Run now, Pause, Resume, or Delete. Open a run to inspect what it did and where it reported.

Respond to an event

A rule is a standing request for a specific kind of event. For example:

@Ryker when someone posts a Terraform plan here, review it for risky changes.

Ryker proposes the event filter, where it will read and reply, what it will do, and when the rule ends. An operator confirms before it is saved under Automations › Rules.

Rules can match Slack, GitHub, and webhook events. Ryker matches the saved filter in code, then assesses the event. It may ignore a duplicate or interim update, react, reply, or start work. A match does not force an unnecessary response.

Manage rules in the console, Slack App Home, or /ryker assignments. Use proactive channel participation for general conversation; use a rule when you want an explicit, repeatable response to a particular event.

Continue existing work after a wait

A follow-up belongs to a request already in progress. Ask “check again in two minutes” or “come back when this merges.” Ryker can also add a follow-up as part of its work.

It can wait for a time, an event, or someone’s answer. Event waits can remain open without a deadline; with a deadline, Ryker can also check back sooner. Only an event matching the wait can resume it.

Pending follow-ups survive restarts and use no model or worker while waiting. Find them under Automations › Follow-ups. Closing the original request stops its follow-up. For a separate future job, create a schedule.

Access and approvals still apply

Saving a schedule or rule does not grant more repository or infrastructure access. Each run uses its environment, and Emisar decides which actions can run or need approval. A past approval or saved memory does not authorize a new action.

The run’s timeline records what started it, what it did, and any result or failure. If work cannot finish, inspect Failures before retrying. To help later runs use your team’s decisions, add memory and guidance.