Build

A trigger decides when a loop should start a new run.

Triggers turn a process from something an operator can run into something that belongs to a clock, an event, or an application. Start manually while you are learning what good output looks like. Automate the start only after the loop is useful and bounded.

Choose who owns the start

The best trigger follows the source of truth for the work:

Use an event trigger when Mobius already receives the provider event. Use HTTP when the caller owns the request and can call Mobius directly.

Manual first, automation second

A manual trigger is more than a test convenience. It gives operators a safe way to run the process on demand and lets you observe real input before work starts unattended.

Once the output is reliable, add the trigger that matches the real use case. Keep the manual path when operators will need to reproduce, backfill, or verify the work later.

Schedule work that belongs to a clock

Use a schedule for recurring work whose subject can be determined at run time: a morning brief, nightly security check, or weekly account review.

Choose a timezone that matches the people or business rule, not the server. Then decide what should happen if one run is still active when the next time arrives. A status check may skip overlap; ordered processing may need a queue.

React to changes with events

Use an event trigger when the loop should begin because something happened: a pull request opened, a table row changed, or a provider delivered a message.

Choose the narrowest event that represents the business moment. Add a condition only when the event still includes cases the loop should ignore, such as draft pull requests or changes outside one repository.

The event becomes context for the run, so steps can use the repository, account, message, or other subject that caused the work. Browse the event catalog to see the events available to a project.

Let an application request work with HTTP

An HTTP trigger is useful when your product or service owns the decision to start. The request supplies the run context, and the trigger gives that caller a stable entry point into the loop.

Inbound HTTP triggers are different from outbound webhooks. An HTTP trigger asks Mobius to begin work. A webhook tells your service that something in Mobius happened.

The interactive API reference documents the delivery contract and idempotency behavior.

Decide how overlapping starts behave

Several triggers can fire while the same loop is active. The loop's concurrency policy decides whether to allow, queue, skip, or replace the new work.

Choose based on the meaning of the input, not the trigger type. Independent pull requests can overlap. Ordered records should queue. A recurring health check may skip. A live preview may keep only the newest request.

Work with triggers in the app

Open Build > Loops, choose a loop, then add or edit its triggers. The loop page shows trigger readiness and recent activity so you can tell whether an event failed to match or a start was suppressed.

Test with a manual run before enabling a schedule or sending a production event. After the first automatic start, open the run and confirm that its input describes the expected subject.

Next

• Put triggers on loops.
• Use trigger context in steps.
• Debug provider delivery with source events.
• Send outbound notifications with webhooks.