Notifications

How Dibbla tells you about tickets and failed deploys — what you get with zero setup, how to route events to Slack or email, and how unsubscribe works.

Dibbla has one notification system for the whole platform: services record events, your organization holds subscriptions that say which events go where, and channels (email, Slack) deliver them. You rarely need to think about that machinery — the defaults below cover the common cases — but every piece of it is inspectable and overridable from your organization settings.

What you get with zero setup

Four defaults exist so the system is useful before anyone configures anything:

• Ticket reporters are notified of replies. When someone replies to a support ticket you filed, you get an email — automatically, scoped to your own tickets only, and never for your own replies. The first such email creates a real subscription in your organization’s list, so unsubscribing (one click, from the email) turns it off for good.

• Connecting a channel announces new tickets there. The moment an admin connects a Slack webhook (see below), a subscription for new support tickets is created on that channel. Configuring the channel is the setup — there is no second step.

• Pipeline alerts subscribe themselves. The first pipeline.run.* event in your organization creates a subscription to all four of them on the channel you have connected, so a scheduled batch that goes red reaches someone even if nobody ever visited this screen. With no channel connected anywhere, nothing is seeded and the default is still waiting for you the day you connect one. Disabling or deleting it is final — it is never re-created behind your back.

• Owners and admins hear about Dibbla access. Every time someone at Dibbla enters your organization, or raises a support session to write, each owner and admin gets an email — see Dibbla access. Unsubscribing turns it off for that person only, for good.

Events you can subscribe to

Subscriptions match an exact event type or a prefix wildcard (support.ticket.*), and can deliver immediately or batched hourly/daily.

The pipeline.run.* events follow a transition, not a run: a pipeline that fails every night alerts once and then says recovered when it works again, and a worker that stays offline for a week is one alert rather than one per missed tick. A run skipped by the concurrency policy, a disabled pipeline and a pipeline with no schedule never alert at all. See Pipelines and schedules for the full rule and for what an alert carries.

Two kinds of subscription, and which one you want

Dibbla has two, and they are not variants of each other:

• Yours. Under Profile settings → Notifications, you follow apps you build, by category, and the notifications reach you as a Slack direct message from the Dibbla bot. Nobody else sees them. This is the one most people want, and it needs no admin. See Follow the apps you build.
• The organization’s. Under Organization settings → Integrations, an admin routes an event type to a shared destination — a Slack channel, a webhook, a Discourse category, an email address. Everyone with access to that destination sees it.

The two never mix. A shared-channel subscription belongs to the organization and carries no person; a personal one belongs to you and is delivered only to you. Adding a channel subscription cannot widen what one person receives privately, and an admin cannot delete or edit your personal choices from the organization screen.

Adding an organization-wide subscription

Organization settings → Integrations, on the notifications card. You need to be an organization admin; a member does not see it.

The event type is a free-text box, and its placeholder reads support.ticket.*. That placeholder is an example, not a limit — and it is the one thing about this screen worth knowing in advance, because nothing on it lists the event types that exist. The card’s own description mentions support replies and failed deploys, so the application.check.*, application.maintenance.* and pipeline.run.* types above are not discoverable there at all: you cannot pick them from a list, and you will not guess them.

So copy the value you want from the table above, exactly as it is written, and paste it in. application.check.failed subscribes to that one event; application.check.* subscribes to all four, which is usually what you want — including recovered, so a fixed app tells you it is fixed instead of just going quiet. application.maintenance.* is the same shape for the maintenance agent. pipeline.run.* is the same shape for pipelines — and the one you rarely have to type, because the first pipeline alert seeds it for you.

Routing events to a webhook

For machine consumers — a bot, an internal tool, your own automation — connect a webhook under Organization settings → Integrations: paste the endpoint URL you want notified. That one value is the whole setup; like the Slack connection, it immediately subscribes new support tickets to the endpoint, and you can add subscriptions for anything else (a deploy.failed subscription on the webhook channel is how a bot hears about failed deploys).

Each delivery is a POST with a JSON array of thin notification objects — identifiers, the event type, the subject and a timestamp, never the full event body — and is signed so your receiver can verify sender, integrity and freshness:

• X-Dibbla-Timestamp: unix seconds at send time.
• X-Dibbla-Signature: v1=<hex> where hex = HMAC-SHA256(key, timestamp + "." + raw request body) and key = SHA-256(your endpoint URL exactly as you configured it).

Your receiver should recompute the signature, compare in constant time, and reject timestamps older than about five minutes (replay guard). Treat the endpoint URL as a secret — it is both the address and the key material, and rotating it (paste a new URL) rotates both. Dibbla refuses endpoints that resolve to private or loopback addresses, follows at most a few redirects, and treats an HTTP 410 Gone from your receiver as “stop sending here”.

Routing events to Discourse

An organization with its own Discourse forum can have notifications posted as topics: connect the Discourse integration with an admin API key, and set the target via the API — PUT /api/integrations/discourse with config: {"url": "https://your-forum.example", "category": 7}. Posts are attributed to the acting user (the person whose action produced the event) through Discourse’s external-id mechanism; a user with no forum account fails the delivery cleanly rather than posting as an admin. The adapter is contract-tested against a Discourse stand-in; the first customer organization to configure it verifies the live pairing.

For agents: notifications over MCP

An agent holding your Dibbla API token can consume the same stream you would get by email: point it at https://mcp.dibbla.com/notifications (bearer token, like the support toolset). notifications_list returns only the calling user’s notifications, and notifications_ack marks one read. Acknowledgements are per-user and idempotent.

Routing events to Slack

An organization admin connects Slack under Organization settings → Integrations: create an incoming webhook for the channel you want and paste its URL. The URL is stored encrypted and never shown back to you.

Each Slack message is a one-line summary plus a link into Dibbla — never the full ticket or event body, since a channel is a wider audience than a ticket thread. If the webhook is later deleted in Slack, Dibbla notices on the next send and disables the connection and its subscriptions instead of retrying a dead URL; reconnecting re-enables delivery.

Linking your own Slack account

The workspace connection above is your organization’s; it says which Slack Dibbla may post into, not which Slack person you are. Dibbla does not guess that from your email address, so the link is something you make yourself, once, under Profile settings → Slack account.

Link my Slack account sends you to Slack’s own sign-in, in the workspace your organization connected, and brings you back. Dibbla keeps two facts from it — the workspace and your Slack user id — plus the display name you publish in Slack, so you can recognise the account on the page. It does not keep your Slack email, your profile or any token of yours: messages are posted by the Dibbla app, using the workspace connection an admin made.

Three things can stop the link, and each says which:

• A different workspace. Slack lets you sign in to any workspace you belong to; only the one your organization connected can be linked. Switch workspace in Slack and try again.
• Already linked to someone else. A Slack account belongs to at most one Dibbla user. Dibbla will not say who holds it — sign in with your own account, or ask them to unlink theirs.
• No connected workspace. An owner or admin connects one first, under Organization settings → Integrations.

Unlink stops personal Slack notifications immediately. It keeps every notification preference you have set, so linking again resumes exactly where you left off — nothing to set up a second time. The same is true when Slack deactivates the account: Dibbla notices on the next delivery, stops sending, and offers you the link again.

Follow the apps you build

Profile settings → Notifications, under your Slack account. Dibbla lists the apps you can follow and, for each one, four categories:

Failed deploys is the one category that only ever brings bad news, and it is named that way on purpose. A deploy that succeeds sends nothing — there is no “deploy succeeded” notification to subscribe to. So a quiet app you deploy to often is a healthy one, not a broken subscription. The other three carry both sides: checks report recoveries as well as failures, maintenance reports runs that completed as well as ones that did not, tickets report replies as well as new reports.

You pick categories, never event types — the event names in the table further up are the organization screen’s vocabulary, not this one. Each app also has a frequency: immediately, hourly, or daily.

Save replaces your choice for that app: exactly the categories you ticked, none of the others. Unticking everything, or the bin icon, stops following the app entirely. Either takes effect on the next event — there is nothing to wait for and nothing else to clean up.

You can only follow apps you build, maintain or administer. That is decided by your role in the organization that owns the app, and it is checked again every time something is about to be sent — so if you leave the organization or lose the role, the app stops notifying you without anyone tidying up. An app you merely have access to as a user is not on the list.

What a personal Slack message says

Deliberately little:

• which app it is about,
• which category the event belongs to,
• the status — a short code such as BUILD_FAILED, proposal or budget_exhausted,
• one link into Dibbla.

And nothing else. Not the check’s summary, not the maintenance agent’s account of what it found, not a proposal’s title, not the ticket subject the customer typed, not the reporter’s email. A Slack message leaves Dibbla’s login behind: it is readable by anyone at your screen, forwardable in two clicks, and kept by Slack. So the detail stays behind the link, where Dibbla decides who may see it.

When a notification does not arrive

Each app you follow shows the outcome of its last notification on the same card, in words: delivered, retrying, or not sent with the reason. Silence has its own sentence too — “nothing has happened on this app yet” — so you never have to guess whether the app is quiet or the channel is broken.

The reasons that need something from you:

• No Slack account is linked to you. Link one above.
• Your linked Slack account is no longer active in the workspace. Link it again.
• The workspace installation stopped working. An owner or admin reinstalls the Dibbla Slack app under Organization settings → Integrations. Your preferences survive this — you do not rebuild them after a reinstall.
• You no longer build, maintain or administer this app. The subscription stopped because your relation to the app did.

A Slack outage or rate limit is not one of these: Dibbla retries a handful of times with a widening gap and, if Slack still refuses, records the attempt as failed rather than sending it twice later. A notification is never delivered twice, and never silently dropped without a reason on this card.

Email and unsubscribing

Notification email is sent by the platform — no per-organization setup. Every message carries a one-click unsubscribe link and the standard List-Unsubscribe headers, so your mail client can offer its own button. Unsubscribing needs no login and disables exactly the one subscription that produced the mail, nothing else. It sticks: the platform never re-enables a subscription you turned off.

For admins: the full picture

Admins manage subscriptions and integrations in Organization settings → Integrations, and can audit what happened through the delivery ledger — every event and every delivery attempt (sent, failed, or dropped) is recorded per organization.

Self-hosting? Delivery channels and the shared ingest secret are configured in the Helm chart — see Self-host with Helm.