Automations
An automation is a job your agent does on its own, without a customer writing first. It can watch a value and alert you, send a daily summary, keep a Knowledge source up to date, or push data to another system. Use an automation when something should happen at a time or on a signal, not in reply to a message.
This page covers automations that run on a schedule. The same automation can instead start on a webhook request or a Peki event: see Triggers.
How an automation runs
Every run goes through the same steps. Each step is optional except the trigger, and a run can stop early.
The rule that keeps automations cheap: check with code first, use the model only when something happened. A check runs one of the agent's Functions without a model, so it costs almost nothing and can run every minute. The model runs only in the task, and only when the check result changed or a condition holds.
Where to find it
Open an agent and click Automations in the sidebar. The page lists the agent's automations with these columns:
| Column | What it shows |
|---|---|
| Name & trigger | The name and a one-line summary, for example "Every 5 min · Check get_crypto_price · When condition holds". |
| Last run | When it last ran and its outcome, such as Sent, No change, Condition not met or Failed. |
| Next run | When the schedule fires next ("in 3 min", "Today 21:00", "Tomorrow 09:00"), read in the automation's time zone. Shows "—" while paused. |
| Cost today | Model cost of today's runs, counted in the automation's time zone. Turns red when it reaches the daily limit. |
| Status | The on/off switch. |
Click a row to open it. An open automation has three tabs: Setup, Runs and Run once. Viewers see the list, the setup and the runs. Editors and above can create, change, run and delete automations.
Automations are not part of the agent's draft and versions. Changes apply as soon as you save, like channel settings. There is nothing to publish for an automation itself.
Create an automation
- On Automations, click New automation below the list.
- Give it a Name (up to 100 characters), for example "BTC oversold alert".
- Under When, keep Schedule and set the interval or weekly times.
- Optionally pick a Check Function and set Continue when.
- Optionally pick an Action, write a Task, add Allowed actions and Notify chats.
- Review Limits.
- Leave Turn on after saving off for now, and click Create automation.
- Open the Run once tab and do a dry run. When the result looks right, switch the automation on with the switch in its row.
A new automation starts paused unless you turn on Turn on after saving. To turn it on, the agent must be published: an automation that is on always runs the published version of the agent.
Describe what you want in the Copilot ("every 5 minutes check BTC's RSI and message me on Telegram when it drops below 30"). It sets up the Function, the automation and a dry run, and asks for your approval before creating it. See Working with the Copilot.
Schedule
Under When → Schedule you choose one of two kinds.
Every
Runs at a fixed interval. Type a number and choose minutes, hours or days.
| Limit | Value |
|---|---|
| Shortest interval | 1 minute |
| Longest interval | 7 days (10,080 minutes) |
| Shortest interval when the task runs every time | 15 minutes |
An interval schedule counts from the moment you set it up: the first run is one interval after you save, not right away. Editing other fields doesn't move it.
Weekly
Runs at set times on chosen days.
- Days: click the day buttons (Mon to Sun). Pick at least one.
- Times: type a time as
HH:MM(00:00 to 23:59) and click Add time or press Enter. Add up to 24 times. Remove one with its close button.
Weekly times are wall-clock times in the automation's time zone. On a daylight saving change, a time that doesn't exist that day (for example 02:30 on a spring-forward night) runs at the next valid time, like cron does.
When the task runs every time (Continue when → Always), weekly times must be at least 15 minutes apart, also across midnight between two selected days.
Time zone
Timezone sets how the schedule, quiet hours and the daily limits are read. A new automation uses your workspace's time zone. Pick any IANA zone, such as Europe/Istanbul or America/New_York, or UTC.
What happens around the schedule
- One run at a time. If a run is still going when the next one is due, the new one is skipped and recorded as Skipped — previous run still going.
- Missed runs are not replayed. If the service was briefly unavailable, the next run happens at the next scheduled time.
- Paused means nothing runs. A paused automation records no scheduled runs.
Check
Check runs one of the agent's Functions without the model. Its JSON result is what the rest of the run works with.
- Pick the Function from the list, or No check.
- Input: the JSON object passed to the Function as its input. It must be a JSON object, for example
{"symbol": "BTCUSDT"}.
Rules for a check Function:
- It must be in the published version of the agent (for an automation that is on) and turned on.
- It can't have Needs approval on: a check runs unattended on every fire.
- During a dry run it may only make
GETandHEADrequests. - The result is kept for the run record and the next comparison up to 16 KB. A longer result is cut and marked "Cut short: the result was too long to keep in full."
If the check fails (an error, a timeout), the run is recorded as failed with the Function's error.
To write the Function, see Functions.
Memory between runs
In automation runs, Functions get ctx.store, a small key-value memory kept per automation:
export default async (input, ctx) => {
const last = await ctx.store.get('lastAlertedPrice');
// ...
await ctx.store.set('lastAlertedPrice', price);
return { price, last };
};
| Limit | Value |
|---|---|
| Keys per automation | 50 |
| Total size (keys + values as JSON) | 8 KB |
| Key names | 1 to 64 letters, digits, _, . or - |
ctx.store exists only in automation runs, for the check, the action and Functions the task calls. Use it so an alert reports only what is new. A value that contains one of the run's secret keys is refused. In a dry run, writes go to a temporary copy that only that run sees: the automation's real memory is never changed.
Continue when
Continue when decides whether the run goes on after the check. Without a check, only Always is possible.
| Option | What it does |
|---|---|
| Always | Runs the task every time. |
| When the result changed | Goes on only when the check result differs from the last real run's result. Key order in the JSON doesn't matter. |
| When a condition holds | Goes on only when all your rules hold on the check result. |
"The last result" is the result of the last real run of the published version. Dry runs and draft runs never change it, so testing doesn't affect what the schedule compares with.
Rules
Each rule has a Field, an Operator and a Value. Add up to 10 rules. All rules must hold.
- Field is a dot path into the check result:
rsi,data.rsi,items.0.price. - A field that is missing or
nullmakes the rule fail ("not found in the check result").
| Operator | Meaning | Value |
|---|---|---|
< <= > >= | Numeric comparison. Numbers in text form ("29.5") count as numbers. | A number |
| equals / not equals | Equal or not equal. Numbers compare as numbers, everything else as text. | A number, true, false or text |
| contains | Text contains the value, or a list has an item equal to it. | Text |
changed % > / changed % < | Percent change since the last real run: (now − last) ÷ |last| × 100. A 2% drop is changed % < -2. | A number |
A changed % rule fails when there is no previous value yet (the first run) or the previous value was 0.
When a run stops at a rule, the Runs tab shows Rule that didn't hold, for example rsi < 30 (was 41.2).
Action
Action runs one of the agent's Functions with write access, without the model, after the condition. Use it to send data to another system, such as posting a lead to your CRM.
- Pick the Function and give its Input as a JSON object.
- Its writes are approved when you save: "Approved when you save. Writes run without asking each time."
- If the Function has Needs approval on, the action doesn't run: it creates an approval request with the exact input instead, and the run shows Action waits for approval. See Approvals.
- With no task, the action's result can be the notification: return
{ "message": "..." }and that text goes to the Telegram chats. - In a dry run, the action's write requests are answered by the system and never sent. The run shows them as "would POST host".
The action is most useful with webhooks and events: see Triggers.
Task
Task (optional) is what the agent does in this run, in your words, up to 4,000 characters:
Write a 2-sentence factual alert: current RSI, price and 24h change. No buy/sell advice.
The agent runs with its own instructions, Knowledge and model, and only the Allowed actions below. Its input is your task, the check result, the previous result when you use When the result changed, and a fixed rule that it states facts only and never gives buy or sell advice.
Things to know:
- Each automation keeps its own hidden conversation per day (in its time zone). It doesn't appear in the Inbox and isn't counted in Analytics.
- The task can't ask for a person (no human handoff).
- If a guardrail blocks the answer, or the model fails, the run fails with that reason.
- Without a task, no model runs at all.
Allowed actions
Allowed actions are the tools the task may call. Click Add and pick from:
- built-in tools,
- the agent's HTTP tools,
- the agent's Functions,
- record tools such as
save_leadsandfind_leads(see Records).
Items marked writes change something outside: an HTTP tool with a method other than GET, every Function, and every save_ record tool. Write actions are approved once, when you save, by someone with the editor role or above. They then run without asking each time.
Add to Knowledge lets the task save notes as Knowledge sources (a tool that adds a titled text source). It counts as a write action too.
If a tool that was read-only becomes a writing tool in a newly published version (for example a GET tool changed to POST), or the check is switched to another Function, the automation pauses itself with "Tools … now write; re-approve the automation (save it again with the publish role) before it runs". Open it, check the setup and save it again.
Notify
Notify sends the result to Telegram through the agent's own bot. The message is the task's answer, or the action's message when there is no task.
- Connect Telegram to the agent first under Channels. Without a bot you see "Connect Telegram first to send messages."
- Click Add chat and pick from the chats that have talked to the bot. Add up to 20.
- To add someone new, click Copy /start link and send it to them. Once they open it and press Start, their chat appears in the list.
Approve each message before it is sent makes every message wait in the Inbox Approvals tab. Approving sends it as shown, and quiet hours don't apply then.
Sending has a time budget of 30 seconds per run, including Telegram's rate-limit waits. Chats not reached in that time are marked failed. If no message could be sent at all, the run fails.
See Telegram for setting up the bot.
Limits
| Setting | What it does | Default |
|---|---|---|
| Runs per day | Most scheduled runs per day (1 to 10,000). Over it, the automation pauses itself. | 1,500 |
| Model cost per day | Most model cost of tasks per day, in dollars (0 to 1,000). Reaching it pauses the automation. | $1 |
| Quiet hours | A time window with no messages, such as 23:00–07:00. Runs are still recorded. | Off |
Days are counted in the automation's time zone.
Quiet hours hold messages: they are not sent later, the run records Held — quiet hours. If the task's only effect is the message (no allowed actions, no Add to Knowledge), the task doesn't even run in quiet hours, so you pay nothing for a message that would be dropped. A window may span midnight. Use quiet hours for "no messages at night"; don't put time rules in the Function or the conditions.
Automation tasks use your workspace's credits like every model call. Before each scheduled, webhook or event run, Peki checks that the workspace has credits left. When it doesn't, the automation pauses itself with "Paused: the workspace is out of credits. Add credits in Settings → Plan & credits, then resume." Add credits, then click Resume. See Plans and credits.
Pausing and automatic pauses
Turn an automation off or on with the switch in its row. Turning it on checks the setup again: the agent, its Functions and its Telegram bot may have changed while it was paused.
An automation pauses itself when:
- it reaches Runs per day or Model cost per day,
- the workspace is out of credits,
- 5 scheduled runs in a row failed ("Paused after 5 failed runs in a row. Last error: …"),
- a write action wasn't approved (see the warning above).
A strip under its row shows Paused automatically: and the reason, with Raise limit (opens the setup) and Resume. Resuming resets the failure count. Editing an automation that paused itself keeps it paused until you resume it.
Run once
The Run once tab runs the automation right now so you can see what it would do.
| Option | What it does |
|---|---|
| Dry run | On by default. "Nothing is sent or written." Checks and reads run for real. Writes, messages and Knowledge additions are only shown. |
| Version | Published or Draft. The draft can only dry-run. |
Click Run. The result appears under the button with its stages and details. The page waits up to 2 minutes; a longer run shows "Still running after 2 minutes; it will show in Runs when it finishes."
- Run once doesn't count toward Runs per day or the 5-failure pause.
- Only one manual run can be in progress per automation; another one is refused until it finishes.
- A real run (dry run off) of the published version sends messages and writes. Real runs always use the published agent.
- Run once works on a paused automation too.
Runs
The Runs tab shows the last 50 runs, newest first. Run records are kept for 30 days. Filter with All, Task ran or Failed.
Each row shows the Time, the Stages the run went through, its Duration and Cost. Dry runs carry a Dry run tag. Click a row to see what it did: the check result, the rule that held or didn't, the action and its requests, tool calls, the agent's answer, and each message with its status (Delivered, Held — quiet hours, Failed, Not sent, Waiting for approval).
| Stage | Meaning |
|---|---|
| Running… | The run is in progress. |
| Checked | The check ran; there was nothing more to do. |
| No change | Stopped: the check result was the same as last time. |
| Condition not met | Stopped: a rule didn't hold. |
| Action ran | The action Function ran (no task). |
| Action waits for approval | The action became an approval request. |
| Task ran | The task ran (no chats to notify, or nothing was sent). |
| Sent to N chats / Would send to N chats | Messages were sent, or would be in a dry run. |
| Held — quiet hours | Quiet hours held the messages. |
| Waiting for approval | The message waits in Approvals. |
| Skipped — previous run still going | The run didn't start because another one was still running. |
| Failed: … | Something went wrong; the reason follows. |
A run that no worker finished within 10 minutes is shown as failed ("Not picked up").
Common errors when saving
The setup is checked against the agent when you save. The message tells you what to fix:
| Message (shortened) | What to do |
|---|---|
| Publish the agent first: an enabled automation runs the published version | Publish the agent, or save the automation turned off. |
| Function … is only in the draft; publish the agent first | The check, action or a tool exists only in the draft. Publish, or dry-run the draft with the automation off. |
| Choose a Function to check first | When the result changed and When a condition holds need a check. |
| Add at least one rule | When a condition holds needs a rule. |
| A task that runs every time needs at least 15 minutes between runs | Lengthen the interval or use a condition. |
| Automations can't ask for a person (request_human) | Remove that tool from Allowed actions. |
| Connect Telegram first (or turn the Telegram channel on) | Connect or turn on the Telegram channel. |
| Chat … is not a Telegram chat of this agent | That person must message the bot first. |
| The automation changed while you were saving | It may have paused itself meanwhile. Reload and try again. |
Example: daily sales digest
A store wants a short summary of yesterday's orders every weekday morning.
| Setting | Value |
|---|---|
| When | Schedule → Weekly, Mon–Fri, 08:30, Europe/London |
| Check | get_yesterday_orders (a Function calling your store API), input {} |
| Continue when | Always |
| Task | "Summarise yesterday's orders in 3 short lines: order count, revenue, top product. Facts only." |
| Notify | The owner's Telegram chat |
Weekly times with an always-running task are fine here: the runs are a day apart.
Example: price alert
Alert when Bitcoin's 1-hour RSI drops below 30, at most once per dip.
| Setting | Value |
|---|---|
| When | Schedule → Every 5 minutes |
| Check | get_crypto_price, input {"symbol": "BTCUSDT"}, returning { "price": 61250, "rsi14_1h": 28.4 } |
| Continue when | When a condition holds: rsi14_1h < 30 |
| Task | "Write a two-sentence factual note with the price and the RSI. No advice." |
| Notify | Your Telegram chat |
| Limits | Quiet hours 23:00–07:00 |
To report each dip only once, let the Function remember it in ctx.store and return a flag such as "newDip": true, then add the rule newDip equals true.
Alerts state facts: values, changes, a threshold crossed. The task rule and the Copilot refuse buy or sell signals and investment advice.