Workers

What is a Worker?

A Worker is a Python script that runs continuously in a cloud sandbox. You write the code in a Worker block on the canvas, click Deploy, and it starts executing on the server.

Workers follow a tick-based model: your code runs at a configurable interval (1 second to 1 hour), with persistent state between ticks.

Code Structure

Every worker defines up to 3 functions:

def setup(ctx):
    """Called ONCE when the worker starts.
    Use this for initialization: set initial state, log startup message."""
    ctx.state.set("counter", 0)
    ctx.log.info("Worker started")


def tick(ctx):
    """Called every tick_interval seconds.
    This is where your main logic lives."""
    count = ctx.state.get("counter", 0) + 1
    ctx.state.set("counter", count)
    ctx.log.info(f"Tick #{count}")


def on_error(ctx, error):
    """OPTIONAL. Called when tick() raises an exception.
    Use this for error reporting or cleanup."""
    ctx.log.error(f"Error occurred: {error}")

Function	Required	When called
setup(ctx)	No	Once, when worker starts
tick(ctx)	Yes	Every tick_interval seconds
on_error(ctx, error)	No	When tick() raises an exception

The ctx Object

The ctx (context) object is your SDK. It provides access to everything:

Adapter	Description	Requires connected block
ctx.state	Persistent key-value storage (Redis)	No
ctx.log	Logging (info, warn, error, debug)	No
ctx.monitor	Real-time dashboard widgets	Monitor block
ctx.http	HTTP GET/POST requests	No
ctx.bybit	Bybit exchange trading API	Bybit block
ctx.ig	IG Markets trading API	IG Markets block
ctx.telegram	Telegram messaging	Telegram block
ctx.files	File read/write/list/delete	File Explorer block
ctx.llm	LLM queries (Claude, Grok, OpenAI)	LLM Agent block

See the full API Reference for all methods.

How to Deploy

1. Add a Worker block to your canvas
2. Connect it to other blocks via edges (e.g., draw edge to a Bybit block)
3. Open the Worker block and go to the Code tab
4. Write your Python code
5. Click Deploy
6. Click Start (in the Control tab)

Tick Intervals

Configure how often tick() is called:

Interval	Use case
1s	Real-time monitoring, HFT
5s	Active trading, live dashboards
10s	Default, general purpose
30s	Moderate polling
60s	Periodic checks
5 min	Background monitoring
15 min	Slow updates
1 hour	Scheduled tasks

You can change the interval without redeploying -- just update it in the Control tab.

Auto-Heal

Workers have built-in error recovery:

• Max Errors: number of consecutive exceptions before auto-stop (default: 5)
• Auto-Heal: when enabled, the system can automatically fix your code using AI and restart the worker

Each successful tick resets the error counter to 0.

Tick Timeout

Each tick() call has a 60 second timeout. If your tick takes longer, it will be killed with a TickTimeoutError. Keep your ticks fast -- use ctx.state to persist progress between ticks if processing large datasets.

State Persistence

All state stored via ctx.state is:

• Kept in Redis during runtime (fast reads/writes)
• Synced to PostgreSQL on worker startup and shutdown (durability)
• Available across worker restarts and redeployments

Your state survives worker restarts, code changes, and server reboots.