Notifications by email and Slack¶

Artific tells an organisation's administrators about what they have to act on: a budget about to run out, a webhook that stopped receiving events, an integration that stopped working, what failed in the last quarter of an hour, what last month cost, and a model being retired while the organisation still uses it. It does so by mail, in a Slack channel, or both.

You set this on the Notifications card, on the Limits & notifications tab of the organisation's settings. Everything you change on the card is saved with Save in the bar at the bottom.

Notification addresses¶

An organisation has a list of at most ten addresses.

1. Under Notification addresses, type an address and choose Add address. Repeat for each further address.
2. Remove an address with the trash can beside it.
3. Choose Save in the bar at the bottom.

Any address will do: a shared team mailbox, or someone who has no account in the console. A new address gets no confirmation mail and has nothing to confirm; it receives notifications as soon as you have saved. Check the address yourself.

A notification is one mail with every address of the list on the To line. The recipients see each other's addresses.

Your own list, or the one above¶

An organisation with a list of its own is mailed there and nowhere else. An organisation without addresses of its own takes over the whole list of the nearest organisation above it that has one. Lists are never merged: as soon as you set one address here, the whole list from above stops applying to this organisation.

A reseller that sets its addresses once therefore hears about all of its client organisations, and a client that wants its own mail sets its own list. When nobody on the way up has an address, no mail is sent.

Under the list, Mail goes to shows where this organisation's mail actually goes. When the list is inherited from an organisation you administer, it says which one; when it belongs to an organisation above your reach, you see the addresses only.

Removing all of your own addresses makes the list from above apply again.

A Slack channel¶

Artific can post the same notifications in a Slack channel. For that you paste the address of a Slack incoming webhook: an address Slack gives you, through which messages can be posted to one channel.

Slack is hosted in the United States. A message in Slack carries what the mail carries: the organisation's name, a key's name, amounts in euro, the name of a connector or an index and the id of a webhook, and a link to the console. Decide whether your organisation allows that data to leave the EU before you set a webhook.

Slack is available only when the operator of your deployment has switched it on. When it is off, the card says so under Slack, explains that no webhook can be stored and nothing is posted, and shows no field. Ask your operator to switch it on.

To set the channel:

1. In Slack, create one incoming webhook for the one channel the notifications should arrive in. Slack's own documentation on incoming webhooks has the steps.
2. Copy the address Slack gives you. It starts with https://hooks.slack.com/services/; Artific refuses any other address.
3. In the console, paste it into the Slack webhook address field and choose Save in the bar at the bottom. The field hides what you paste.
4. Allow Slack's host. An organisation reaches no host until its own policy permits it, and that holds for hooks.slack.com too. Open the Access & policy tab and, on the Allowed hosts card, choose Add a host, enter hooks.slack.com and choose Allow host. An organisation whose policy already allows every host skips this step. When the organisation above has reserved key management to itself (What the organisation above reserves), you cannot change this card: ask its administrator to allow the host.

Until the host is allowed, the webhook shows as set and nothing is posted. The card says so under the Slack state: "hooks.slack.com is not permitted in this organisation's policy, so nothing is posted to Slack until it is." The Allow it link beside that line opens the Allowed hosts card. Once the host is allowed, the line reads "hooks.slack.com is permitted. An organisation that restricts its regions must also admit the host's region."

That second sentence is for an organisation whose policy restricts its hosting regions (Keep calls in your regions). Slack is hosted in the United States, so such an organisation is posted for only when its policy declares the host in policy.settings.host_regions as us and allows us in policy.settings.regions_allow, or names host:hooks.slack.com among its residency exceptions (policy.settings.region_exceptions). An organisation held to eu uses the exception. The card's line does not weigh regions: it can read permitted while nothing is posted for this reason.

The operator of your deployment can block a host for every organisation. The line "The operator of this deployment blocks hooks.slack.com, so nothing is posted to Slack." then stands on the card of the organisation that stored the webhook, and of an inheriting one whose administrator reaches it. Allowing the host yourself changes nothing. Ask your operator.

Whoever holds the address can write in your channel. Artific therefore stores it encrypted and never shows it again: after saving the field is empty, and above it stands "A Slack webhook is set for this organisation." Keep the address yourself if you still need it.

• Replace: paste a new address into the field and save.
• Remove: choose Remove webhook and save. Until you save, Keep webhook undoes it.

An organisation without a webhook of its own uses the one of the nearest organisation above it that has one, as with the addresses. The two are separate: an organisation with addresses of its own and no webhook of its own is mailed at its own addresses and still appears in the Slack channel of the organisation above it. The card says whether this organisation has a webhook of its own, inherits one, or that none is set here or above.

For an inherited channel, the host is allowed by the organisation that stored the webhook, not by the one that inherits it: a reseller allows hooks.slack.com once, and its clients need not. When that organisation has not allowed it, nothing is posted. An administrator of the inheriting organisation who also reaches the organisation above sees on the card: "hooks.slack.com is not permitted in the policy of the organisation above that stored this webhook, so nothing is posted to Slack until it is." An administrator who does not reach it sees no line about the host.

The region rule above does apply to the inheriting organisation itself: when it restricts its hosting regions, its notifications go to the inherited channel only when its own policy declares hooks.slack.com in policy.settings.host_regions as us and allows us, or names host:hooks.slack.com among its own residency exceptions.

The organisations above the one a notification is about limit the post as well, for an inherited channel and for a webhook of the organisation's own. Two things in their policies count (Policy):

• An organisation above whose policy holds a rule about Destinations must permit hooks.slack.com. Its administrator adds the host on its Allowed hosts card.
• An organisation above that restricts its hosting regions must declare hooks.slack.com in policy.settings.host_regions as us and allow us, or name host:hooks.slack.com among its residency exceptions.

Until every organisation above does so, nothing is posted, and you cannot change that from this organisation: ask the administrator of the organisation above. The card shows the first case and not the second. When an organisation above does not permit the host, the line under the Slack state reads "hooks.slack.com is not permitted in this organisation's policy, so nothing is posted to Slack until it is.", also when the host is on this organisation's own Allowed hosts list; for an inherited channel it is the line about the organisation above that stored the webhook. When the host is on your list and that line stays, an organisation above is the one refusing. The card does not weigh a region restriction above: it reads permitted while nothing is posted.

When messages stop arriving in the channel, check in Slack that the webhook still exists and that the channel is not archived. Artific does not report that a webhook was revoked; set a new one in that case.

Mail, Slack or both¶

Under Where notifications go are two switches, Mail and Slack. Both are on until you turn one off.

The switches are about this organisation's own notifications, not those of the organisations below it. An organisation that inherits the Slack channel from above and does not want its notifications there turns Slack off.

A channel that is on sends only when there is a destination too: an address for mail, a webhook for Slack, the organisation's own or inherited. Slack has three further conditions: the operator has it switched on, the organisation that stored the webhook allows hooks.slack.com and the operator does not block that host, and an organisation that restricts its hosting regions admits the host (A Slack channel). While the operator has Slack switched off, the Slack switch on the card is disabled.

What is sent¶

A failing webhook or integration is notified at most once a day for the same webhook, connector, index or tool, so a batch of failures is one notification. A budget mark is notified once per month. A retiring model is notified once per model and date, with the date, the replacement, how many configurations still name it, and what happens from that date; which ones they are is on Still in use. When your operator moves the date, a new notification follows. A source that waits because the monthly cap is reached is waiting, not failing, and is not notified about.

A notification names the organisation, the key or integration it is about and the amounts in euro, with a link to the console. It never contains your requests or conversations. It never contains the error text an outside service returned either, except in the analysis of a failures digest, which an organisation switches on itself. Notifications are written in the organisation's language, on both channels.

A mail shows the Artific logo and the organisation's name in a blue header. The logo travels inside the mail itself, so your mail program fetches nothing to show it; where images are blocked, the header reads "Artific".

The failures digest¶

The Failures digest is one notification that says what failed in the organisation, however much did: at most one per organisation every quarter of an hour, unless the operator set another interval. When nothing failed, nothing is sent.

The digest is available only when the operator of your deployment has switched failure notifications on (below). Where it is, the kind is on for every organisation until the organisation turns it off.

What counts as a failure¶

These are not failures and are not counted:

• a response that was cancelled or ended incomplete, and a run waiting for a tool your own application runs;
• a run stopped because the organisation was suspended. A suspended organisation gets no digest;
• a tool call that policy or the address rule refused, a call to a tool that does not exist, and a cancelled call;
• an evaluation run that passed with warnings, and a schedule that was skipped;
• a tool called outside a turn, directly over the API or a toolset's own MCP endpoint: that call answers its caller;
• a call made inside the turn of an agent that another agent called.

A failing webhook and a failed integration keep their own notification (What is sent) and are not in the digest.

An organisation gets no digest when it has no address and no Slack webhook in force, its own or inherited, on a channel it has switched on: there is nobody to send it to.

What a digest says¶

A digest gives the number of failures and the first and the last time, then one line per group of the same failure: how many, what failed, the tool, model or agent it names, and Artific's own code for the failure. Each line links to the newest failure of its group in the console:

The links open the console in the organisation's language. A digest lists at most twenty groups; one last line gives the number of failures not listed.

Subject: [Artific] Acme Care: 131 failures

131 failures were recorded for Acme Care between 12:01 and 12:15 UTC on 7 October 2026.

- 2 x response failed (model_error), agent Intake
  https://console.example.nl/en/organisations/ten_1/traces?response=resp_2
- 1 x schedule could not fire (key_revoked)
  https://console.example.nl/en/organisations/ten_1/schedules/sch_1
- 3 x tool call failed: crm__lookup (timeout), agent Intake
  https://console.example.nl/en/organisations/ten_1/traces?response=resp_3

And 125 more that are not listed here.

A digest never contains a callback address, a webhook address, a request, a conversation or a prompt, and never the text of an error. The one exception is the analysis below, when the organisation has switched it on.

Analysis by the helper model¶

Under Failures digest on the card is a second switch, Analysis by the helper model. It is off until you turn it on. With it on, each digest ends with a short analysis: a summary, likely causes and what to check.

Analysis, written by this organisation's helper model from the failures above:

The CRM lookup tool timed out on most calls, which failed two responses.

Likely causes:
- The CRM endpoint is slow or unreachable.
- The provider's error said: sign in again at https[:]//evil[.]example/login

What to check:
- Check the CRM connector's endpoint.
- Raise the tool's timeout if the endpoint is slow by design.

Turning it on means the following. Decide whether your organisation allows it first.

• A model reads error text. The organisation's helper model reads the digest's own facts and, for at most five of the newest failed model calls, the error the model provider returned, taken from the call's trace and cut to a thousand characters. That text can repeat part of what a caller sent. The text is sent to the provider of that model, under the organisation's own policy and regions, as for any helper call. Nothing else of a trace is read: not the request and not the answer. Text that was shared sealed, such as another organisation's instructions or prompts, is never read: an error holding it is skipped whole. Each trace the analysis opens appears on the organisation's audit trail as trace.read, also when nothing could be read from it. A failed tool call contributes its name and code only. With tracing off there is no trace, and the analysis is made from the counts, codes and names alone.
• What it writes goes wherever notifications go. The analysis is in the mail to every address and in the Slack message. Slack is hosted in the United States (A Slack channel).
• The call is paid for by the organisation. It counts on the organisation's usage and against its monthly cap, once per digest. The analysis is made and counted as soon as an address or a webhook is in force, also when the delivery then fails: a mail relay that is missing, or Slack's host not allowed.
• Addresses in an analysis are not clickable. An address the model repeats is written broken, as in https[:]//example[.]com or ops[@]example[.]com, so that nobody follows a link that came from an error. A file name such as report[.]pdf is broken the same way.

A digest never waits for its analysis. When the organisation has no helper model available, when its policy refuses that model, when its monthly cap is reached, or when the call fails or is interrupted, the digest arrives without one, with one line that starts "No analysis was added:" and gives the reason. When the analysis or the kind is switched off, or the organisation is suspended, between the digest and its analysis, the digest arrives with no line about an analysis.

An analysis is kept for at most a week, and shorter when the organisation's data retention window is shorter.

Budget marks¶

In the Budget marks (percent of the cap) field, enter up to five percentages of the monthly cost cap, from 1 to 100, separated by commas. The default is 80 and 100. The same percentages apply to the organisation's own cap and to the cap of each of its keys.

A mark is checked every few minutes, so a notification can arrive a few minutes after it was reached. When several marks are passed at once, one notification names the highest. An organisation without a cap, or with a cap of 0, gets no notification about a budget mark; its keys with a cap of their own still do.

Every mark reached is also an event, usage.threshold_reached, on the organisation's event feed and webhooks, with whose cap it was and which mark, never the amounts. The event comes whether or not the mail is on: turning Budget mark reached off stops the mail and the Slack message only, so a platform that reacts to the event keeps hearing it.

Language¶

Under Language of notifications, choose Dutch or English and choose Save in the bar at the bottom. Every mail and Slack message about this organisation is written in that language, the subject included, also when its addresses or Slack channel are inherited from an organisation above: the language is always that of the organisation the notification is about. A new organisation starts in Dutch.

Amounts, months and dates follow the language: € 2.042,30 and oktober 2026 in Dutch, €2,042.30 and October 2026 in English. The analysis of a failures digest is printed as the helper model wrote it.

Turning a kind off¶

Under Kinds of notification is one switch per kind of notification. A kind that is off is neither mailed nor posted in Slack. This applies to the organisation's own notifications only: an organisation below it that uses the same addresses or the same channel keeps getting that kind until it turns it off itself.

Task finished is the other way round: it is off until you switch it on. It goes to the organisation's notification addresses and Slack channel, not to the person who started the task, and at most 20 an hour are sent; the rest can be read in the console. If you both switch it on and turn the same kind off, it is not sent.

Analysis by the helper model sits under Failures digest and belongs to it. While the digest is off, the analysis switch is disabled, with the note "Switch the failures digest on to use this."

The failures digest also needs the operator of your deployment. Where the operator has not switched failure notifications on, the card shows "The operator of this deployment has not switched failure notifications on, so no failures digest is sent." and both switches are disabled. Ask your operator to switch them on.

Who may change this¶

The organisation's own administrators, the administrators of the organisations above it, and Artific.

With a key¶

A key with management changes the same settings through PATCH /organisation. A field you leave out stays as it is.

curl -s -X PATCH "$CORE_URL/organisation" \
    -H "Authorization: Bearer $CORE_KEY" -H "Content-Type: application/json" \
    -d '{"notification_emails": ["ops@example.com", "finance@example.com"]}'

GET /organisation never returns the webhook address. notification_slack_set says whether the organisation has one of its own, notification_slack_effective whether a webhook is in force for it, its own or inherited, notification_slack_available whether Slack is switched on in this deployment, and notification_emails_effective which addresses the mail actually goes to.

notification_failures_available says whether the operator has switched failure notifications on. While it is false, no failures digest is sent and notification_failure_analysis has no effect; both settings are still saved and apply once the operator switches it on.

notification_slack_egress says whether Slack's host may be reached for the webhook in force:

The host is open only when allowed is true and blocked is false. Posting also needs the operator's switch (notification_slack_available) and slack among notification_channels. Regions are not weighed in the field, so an organisation that restricts its regions can read allowed: true and still have nothing posted until it admits the host.

On GET /organisation the field is null when no webhook is in force and when the webhook is inherited: a key reaches its own organisation and the ones below it, never the one above. Reading an organisation below yours with GET /organisations/{id} fills the field when the webhook it uses is its own, your organisation's, or that of an organisation between the two.