Great question. Assuming you’re using Prefect 3.x Automations with the “Call a webhook” action: - The recommended way to keep a Bearer token out of the UI is to store it as a workspace Variable marked as Secret, then reference it in the webhook’s headers using Jinja templating. - Headers and body fields in the webhook action support Jinja templates and can resolve Variables at runtime. The value is redacted in the UI and not logged. Two common patterns: 1) Token as a single secret value - Create a workspace Variable, e.g. name:

WEBHOOK_TOKEN

, value: your token, check “Secret”. - In the webhook action headers: - Key:

Authorization

- Value:

Bearer {{ variables.WEBHOOK_TOKEN }}

2) Token inside a JSON/dict variable - Create a workspace Variable, e.g. name:

WEBHOOK_CREDS

, value:

{
  "token": "abc123",
  "other_key": "value"
}

mark it “Secret”. - In the webhook action headers: - Key:

Authorization

- Value:

Bearer {{ variables.WEBHOOK_CREDS.token }}

Notes - Variables are resolved server-side at runtime and redacted in the UI; the literal token will not be shown in the automation or logs. - Make sure you don’t wrap the Jinja expression in extra quotes—use it as shown. - If you need per-environment tokens, create workspace Variables with different values in each workspace. Alternative (if you can’t use Variables in your environment/version) - Create an automation that “Runs a flow” instead of calling the webhook directly. In that flow, load a Secret/JSON block and make the HTTP request with the token. This keeps the token entirely in flow code/block storage. If you’d like, share whether your token is a single string or part of a dict, and I can provide an exact header snippet for your setup.

Thanks for the detail — this helps. Here’s how Automations handle actions in Prefect 3.x and why you might see what you observed. How an Automation runs a “Send a notification” action - Trigger evaluation: The trigger watches for matching events. When conditions are met, the trigger “fires” and records a trigger-fired event. - Action execution: Each configured action is then executed asynchronously by the Automations service. For “Send a notification,” Prefect: - Loads the notification block you selected - Calls the block’s notify method (e.g., Slack/Webhook/Email) with your subject/body - If the call raises (e.g., timeout), the action is marked failed - Events: The trigger firing and the action execution are separate. A trigger doesn’t “fail” — it either fires or does not. Failures (like timeouts) happen at the action step. Important implications - No “trigger failed” event: Because the trigger already fired successfully, you will not see an “automation trigger failed” event when the notification action times out. If anything fails, it’s the action, not the trigger. - Retries: The built-in “Send a notification” action is not retried by Automations. If the block call times out, the action is recorded as failed and stops there. - Why you might see the block loaded multiple times: - Multiple actions configured: If you used the same notification block in both “When trigger fires” and “When trigger resolves,” the block will be loaded twice (once at fire, once at resolve). - Multiple firings: If your trigger criteria matched more than once (e.g., repeated or similar events), you’ll get one action per firing — each loads the block. - Service reprocessing after interruption: If the Automations service restarts or loses acknowledgement mid-call, it can reprocess the same action, resulting in another block load. - Multiple automations targeting the same event: Overlapping automations can each load the same block. What to check - In the Automation detail, confirm whether the notification is configured on both “When trigger fires” and “When trigger resolves.” - Check if the trigger matched more than once (Events page filtered to your object/flow/task and timeframe). - Confirm there aren’t multiple automations pointing at the same event pattern. - Review server logs around the time of the timeout for any service restart/reprocessing. Recommendations - Increase the block timeout to accommodate the remote service latency. - If you need retries/backoff, prefer “Run a flow” as the automation action and do the notification inside that flow. You can then use Prefect task retries or your own HTTP retry strategy, which gives you control and observability. - Keep the notification in just one place (“When trigger fires” or “When trigger resolves”) to avoid double sends. Docs for reference - Creating automations - Event triggers concepts - Notification blocks API If you can share: - The notification block type and its timeout value - Whether the action is on “fire,” “resolve,” or both - Timestamp(s) and a link to the automation …I can help pinpoint whether this was multiple firings vs. reprocessing vs. config.