Notifications and the Action Log

Work notifications

The bell in the header shows events that need attention. Notifications keeps a history: open an event, read the reason, and follow its link to the relevant run or resource. Marking a notification as read does not fix a run error.

Check the event time first: an error may relate to an old run, while a later one has succeeded. For a repeated refusal, check run logs, source settings, and limits.

Webhook recipients

You can configure an external event recipient in notification settings if your role allows it. Use your server's address, select events, and test delivery. A webhook is different from an export: it reports an event, while catalog data is obtained through an endpoint or delivery.

Events are run.finished, run.failed, and quality.alert; the test request is ping. The X-Parser-Delivery header carries a delivery UUID useful for deduplication. X-Parser-Signature contains sha256= followed by an HMAC-SHA256 over the raw body bytes using your secret. Verify the signature before parsing JSON, using a constant-time comparison.

The receiver should acknowledge a request quickly and handle repeated delivery without repeating the operation. Protect the address and verify the signature configured for it. Keep the recipient secret on the server, not in a public website page.

Action log

The Log shows significant changes: who did what and when. It helps distinguish a manual edit from an automatic run. Viewing it requires the relevant permission. In a team, the log covers the workspace rather than only your own actions.

Look for money spent in the balance log and technical messages about a collection inside its run. These logs answer different questions.