Notifications

Synq can tell you about the things that need you: a failed deploy, an app that crashed, a server running out of disk, a certificate that couldn't renew. You decide where messages go (channels) and what you want to hear about (events).

Channels belong to you: every member of the organization sets up their own. You only get notifications about projects, servers and other resources you have access to.

Add a channel

To remove a channel, press its delete button and confirm "Delete this channel? Subscriptions using it will stop." Secrets you enter (webhook URLs of chat services, tokens) are stored encrypted and never shown again; the list only says whether they are set.

Channel setup

Email needs a way to send mail

Email notifications go out through the instance's outgoing mail (SMTP under Settings → Email, or the built-in mail server). If none is set up, the form warns "No email server is set up on this instance, so email notifications won't be delivered." with Set up SMTP →, and Send test fails with that reason instead of pretending to work. Messages arrive with the subject [Synq] <event>.

Webhooks

Synq sends a POST with Content-Type: application/json and User-Agent: Synq-Webhook/1.0:

{
  "id": "d8c1...",
  "category": "deploy.failed",
  "organizationId": "org_...",
  "resourceType": "deployment",
  "resourceId": "dep_...",
  "payload": { "eventType": "deployment.failed", "...": "event details" },
  "createdAt": "2026-09-26T10:15:00.000Z"
}

Each request carries X-Synq-Signature-256: sha256=<hex>, an HMAC-SHA256 of the raw body with the channel's signing secret. Synq generates the secret when the channel is created. The panel doesn't display it: to verify signatures, create the channel through the API (the response includes the signing secret once, as secret) or set your own with hmacSecret. See the Notifications API.

The receiver must answer 2xx within 10 seconds. Redirects are not followed.

Receivers on your own network

By default Synq only delivers to public https:// addresses. To send to a webhook, ntfy, Gotify, Mattermost or Matrix server on your private network (or to plain http://), set NOTIFY_WEBHOOK_ALLOW_INTERNAL=true in ~/.synq/compose/.env on the server and apply it the same way as the certificate authority settings.

In-app

The in-app channel stores notifications inside Synq instead of sending them anywhere. It isn't offered in Add channel: create it through the API (kind: "in_app", verified straight away) and read it with GET /api/notifications/deliveries. The panel doesn't have an inbox view for it yet.

Choose what to be notified about

What to be notified about is a table of events. Tabs across the top filter it: All, Deployment, App health, Backups, Jobs, Domains & SSL, Members and Mail.

Each row has:

How the two levels combine:

• If you have made your own choice for an event (Notify me), that is what happens, on all your verified channels.
• If you haven't, the organization default applies: when the event is on, it goes to your verified channels of the default kinds.

So an admin can make sure everyone hears about failed deploys by email, and each member can still turn events on or off for themselves. The checkbox is disabled until you have a channel ("Add a channel first to subscribe to events.").

Two things to know:

• Notify me covers the channels you have when you tick it. After adding a new channel, untick and tick the event again to include it.
• The organization default only reaches channels of its Delivery channels kinds, email unless an admin chose others. If your only channel is, say, Slack, tick Notify me for the events you want (or ask an admin to add Slack to the defaults).

Events

Server thresholds are set per server; see Server monitoring and alerts. App health events come from the Container health watch job, which checks containers once a minute; each outage sends at most an alert, an escalation and a recovery, not one message per minute.

Urgency on push channels

ntfy, Gotify, Pushover and Matrix get a priority that matches the event:

Pushover's emergency priority, which repeats until acknowledged, is never used.

Delivery and retries

Messages are queued and sent within seconds. A failed send is retried, up to 5 attempts in total; after that the delivery is marked failed with the service's error. A message is dropped if its channel was deleted, disabled or is no longer verified, or if the recipient lost access to the resource.

Related