Skip to main content
You need authority to execute the target and configure its trigger. Use a test workspace or bounded collection before enabling recurring work.

Choose the target

Open the target’s trigger controls. Confirm its identity and published configuration. A custom Ingest job requires a successful test of the same job/version before its trigger can be enabled. A Format job accepts webhook deliveries only.

Configure a schedule

  1. Choose Schedule and set the recurrence and explicit time zone.
  2. Check the next expected occurrence against your intended local time and daylight-saving rules.
  3. Confirm the target inputs, resource limits and expected effects.
  4. Enable the schedule deliberately. The enabling user becomes its execution principal.
  5. Inspect the first occurrence and resulting action/run record.
The default time zone is UTC. The schedule skips an overlapping occurrence call. Runs started by separate completed calls can still overlap; a job schedule also refuses a job already in flight. Inspect missed or refused occurrences before starting catch-up work. A refusal can disable a schedule. Restoring access does not prove that earlier periods ran.

Configure a webhook

A workspace Owner configures a workflow webhook. Select the supported verification mode and retain the endpoint and one-time credential securely. Use the declared delivery identity header. Repeating an identity joins the existing occurrence. Without one, identical body bytes within the same UTC hour can be treated as one delivery. The default token mode uses x-cortex-webhook-secret and x-cortex-delivery-id. Supported provider verification also includes GitHub, GitLab and Google modes. Send one small authorised test request. Then repeat its identity and confirm no second logical action starts. Use a new identity for a genuinely new occurrence. The inbound body limit is 1 MB. A workflow delivery merges its body over stored input at the top level. Inspect the final Entry input. Format jobs also enforce their accepted media type.

Inspect starts and refusals

Read the occurrence’s completed, pending and refused actions separately. In grouped job scopes, one refused action does not stop every independent permitted action. The principal’s current permissions, clearance, dependencies, workspace lock and limits are checked at dispatch. A final webhook refusal leaves the webhook enabled; a final schedule refusal can disable its schedule. Webhook acknowledgement does not grant the sender run-read access. Inspect the run from the authorised Cortex interface. A notification trigger signals that a source changed and makes the job fetch it. A condition watch evaluates new evidence. Neither has the same meaning as delivering new source bytes through a webhook. See Configure a condition watch and inspect alerts and Run ingestion and inspect processing.