Notifications
When something needs attention — a Stripe key expired, a teammate joined, a payment failed — Ploxir surfaces it in three places: the bell at the top of your dashboard, your inbox (depending on your preferences), and your team's Slack or Discord channel (if you configured one). This page covers all three, plus the alerting behavior behind the most common notification: a data source breaking.
The in-app bell
The bell icon in the dashboard header shows a red unread count (capped at "99+"). Click it for a list of your 30 most recent notifications — newest first, unread bolded. Each row shows a severity icon (info / warning / success / announcement), the message, and how long ago it happened. From each row you can:
- Click the row to mark it read. Clicking deliberately does not navigate anywhere — so you can triage a stack of notifications without losing your place.
- Open the linked page via the small arrow that appears on hover (bottom-right of the row) — it jumps to the failing source, the project, or wherever the notification points.
- Dismiss via the X that appears on hover (top-right). Dismissing also marks the row read, so the unread count drops.
The header offers Mark all read and Clear all (dismiss everything). Dismissing is permanent from your point of view: there is no archive browser, so a dismissed notification cannot be brought back. Between the 30-item window and dismissal, treat the bell as a recent-events feed, not a permanent log.
One bell, per-workspace preferences
The bell is personal and global: it shows your notifications from every workspace you belong to, in one list — a source failure in workspace B is visible while you're working in workspace A. What's scoped per workspace is the preferences: which categories reach you, and on which channel, is decided by your settings in the workspace the notification came from. Muting workspace activity in workspace A doesn't mute it in workspace B.
Categories
Every workspace notification belongs to one of these categories:
- Security & account — new sign-in from an unknown device, password / 2FA changes, recovery codes. Required: always in-app and email; the toggles are locked.
- Data source failures — a connected source stopped working and its widgets are going stale. Default: in-app + email both ON.
- Plan nudges — in-app hints when this workspace hits a plan limit (e.g. project cap reached). In-app only; default ON.
- Workspace activity — member invited, joined, left, or role-changed; workspace renamed; ownership transferred. Default: in-app ON, email OFF.
- Product updates — new connectors, new widget types, major releases, scheduled maintenance. Default: in-app ON, email OFF.
- Marketing newsletter — occasional emails about how teams use Ploxir. Email only, explicit opt-in.
Billing is different: your plan belongs to your account, not a workspace, so billing notices go to the subscriber only and aren't per-workspace toggles. Critical notices (payment failed, card expiring, scheduled cancellation, beta ending) always reach you in-app and by email; informational ones (receipts, upcoming renewals, plan changes) appear in-app only. See Plans & billing for the plan model itself.
Preferences & email digests
Go to Settings → Notifications in the active workspace. You get a category × channel matrix — toggle in-app and email independently for each category. Changes save instantly. Preferences are stored per user × workspace, so your choices never affect teammates, and each workspace is tuned separately.
Below the matrix, Email frequency chooses how category emails are delivered: Real-time (each event as it happens), Daily digest, or Weekly digest. With a digest mode selected, non-critical emails are held and rolled into one summary email of your recent notifications — the daily digest goes out each morning (around 08:00 UTC), the weekly one on Mondays. A digest is skipped entirely when nothing happened, and dismissed notifications aren't included.
- What bypasses the digest: security emails and critical billing notices always send immediately, regardless of the setting.
- One digest per person: notifications live in one per-user list, so you get a single digest covering everything — not one per workspace. If you picked different cadences in different workspaces, the shorter one (daily) wins.
Source-health alerts
The most important notification Ploxir sends: a data source stopped syncing (an expired OAuth token, a revoked API key, a failing poll). Until it's reconnected, every widget reading it shows stale data — so this category defaults to in-app + email ON.
When a source breaks
- Alerts fire on the transition from healthy to broken — once per outage, not once per failed sync attempt.
- Alerts are coalesced: when one root cause takes down several sources of the same platform at once (say, one revoked Stripe secret killing five Stripe sources), you get a single alert naming up to five of them ("and N more" beyond that) instead of five duplicates. Sources with identical names are qualified by their project name so you can tell them apart.
- To make that grouping possible, delivery is debounced by about 90 seconds — the alert waits briefly to collect sibling failures. Expect it a minute or two after the failure, not instantly.
When it recovers
A matching all-clear ("… is working again") fires when the sources sync successfully again — coalesced the same way, so one recovery covers the whole group.
Still-broken reminders
If you ignore the first alert, Ploxir nags: a source that has been failing for 3, 7, and 14 days triggers a reminder at each threshold (checked once a day). Reminders are grouped per platform per workspace — five dead Stripe sources produce one reminder, not five — and each threshold fires at most once per outage. Dismissing the bell row doesn't re-trigger it. The reminders stop when the source works again — open it and use the Reconnect button (see Connecting sources) — or when you remove the source.
Billing notices
Billing notifications are account-level: they go to the subscriber (the account that owns the plan) only, never fan out to workspace members, and have no preference toggles. Severity decides the channels:
- Critical — in-app + email, always: payment failed, card expiring, subscription cancellation scheduled, and beta access ending (reminded 30, 7, and 1 day out). Missing one of these could cost you your plan, so they behave like security alerts.
- Informational — in-app only: receipts, upcoming renewals, plan changes and activations. These never email you.
Slack & Discord delivery
A workspace can forward team-relevant notifications to a Slack or Discord channel via the provider's Incoming Webhook. Configure once per workspace (Owner or Admin role required) and everyone in the channel sees them. Each message carries the workspace name, a severity color, and a link back to the relevant Ploxir page.
Setup — Slack
- Go to Slack > Apps > Incoming Webhooks, click Add to Slack, pick the channel, and copy the webhook URL (it looks like
https://hooks.slack.com/services/T…/B…/…). - In Ploxir, open Settings → Notifications → External delivery → Connect Slack. Paste the URL. Ploxir validates the shape and rejects anything that isn't a real Slack incoming-webhook URL.
- Click Test — this works before saving. A message titled "Test from Ploxir" should appear in the channel.
- Click Save.
Setup — Discord
- Open the Discord channel you want messages in → Edit channel → Integrations → Webhooks → New Webhook. Name it "Ploxir" (or anything), copy the webhook URL (
https://discord.com/api/webhooks/…). - In Ploxir, open Settings → Notifications → External delivery → Connect Discord. Paste the URL.
- Test, then Save.
What gets forwarded
Only a curated subset of notifications posts to the channel:
- Data source failures — a connector broke or recovered, plus the one-time confirmation when a newly connected source pulls its first data.
- Workspace activity — member invited / joined / left / role-changed, ownership transferred.
Everything else deliberately stays out of the channel:
- Billing — account-level and subscriber-only; a team channel never sees another member's billing.
- Security & account — personal to each account; delivered to that person in-app + email, never to a shared channel.
- Product updates and marketing — would spam the channel.
How the URL is stored
The webhook URL is the credential — anyone holding it can post to your channel. Ploxir treats it as sensitive and masks it in the UI: once saved, the settings page shows only the host plus the last five characters (hooks.slack.com/…/abc12), never the full URL again. Changing it requires re-entering a complete URL.
Removing or rotating
Settings → Notifications → External delivery → Remove clears the URL; posting stops immediately. To rotate, regenerate the webhook in Slack / Discord, click Change, paste the new URL, and Test — no need to remove the old one first.
Emails Ploxir sends
The complete list, what triggers each, and whether you can turn it off:
| When | Can you turn it off? | |
|---|---|---|
| Verification link | At signup, and when changing your email address | No — transactional |
| Welcome | Once, right after signup | No — one-time |
| Password reset link | When you request one | No — transactional |
| Security alerts | Password changed, 2FA enabled / disabled, backup code used, new-device sign-in, email or sign-in method changed, account locked | No — Security & account is mandatory |
| Account deletion | Deletion scheduled (7-day grace), canceled, or completed | No — transactional |
| Workspace invitation | Someone invites your email address to their workspace | No — sent to the invited address |
| Your invite was accepted | Someone accepts a workspace invitation you sent | Yes — Workspace activity email toggle (off by default); respects digest mode |
| Removed from a workspace | An admin removes you | No — you're no longer a member, so preferences no longer apply |
| Workspace deleted | A workspace you belong to is deleted — sent to every member except the person who deleted it | No — transactional |
| Role changed / ownership transferred | Your role changes, or a workspace ownership transfer involves you | Yes — Workspace activity email toggle (off by default); respects digest mode |
| Source stopped working / recovered | Coalesced break and recovery alerts, plus 3 / 7 / 14-day still-broken reminders | Yes — Data source failures email toggle (on by default); respects digest mode |
| Notification digest | Daily (~08:00 UTC) or weekly (Mondays), when you chose a digest mode and had notifications | Yes — switch Email frequency back to Real-time |
| Getting-started nudge | Once, ~2 days after creating a workspace that has no data source connected yet | No — one-time |
| Critical billing | Payment failed, card expiring, cancellation scheduled, beta ending (30 / 7 / 1 days out) | No — sent to the subscriber, always |
FAQ
Five of my sources broke and I only got one alert — is that a bug?
No, it's the design. Same-platform failures inside a ~90-second window almost always share one root cause (one revoked key), so Ploxir sends a single alert naming all affected sources — and a single all-clear when they recover — instead of N duplicates in your inbox and channel.
Why am I being re-notified about a source I already know is broken?
Sources that stay broken get reminders at 3, 7, and 14 days — each threshold once per outage. A broken source silently freezes every widget reading it, which is easy to forget after dismissing the first alert. Reconnecting the source stops the reminders; dismissing the notification does not.
Why did the failure alert take a couple of minutes to arrive?
Delivery is debounced by about 90 seconds so that sibling failures can be grouped into one alert. Add queue pickup time and you should expect an alert one to two minutes after the failing sync, not instantly.
I dismissed a notification — can I get it back?
No. Dismissing removes it from your bell permanently, and the bell only holds your 30 most recent notifications anyway. Anything that matters long-term (a broken source, a failed payment) also lives in the product itself — the source card shows its error state, the billing page shows your subscription — so nothing is lost with the row.
Clicking a notification doesn't take me anywhere. How do I open the linked page?
Clicking the row only marks it read — that's intentional, so triaging doesn't yank you around the app. Hover the row and click the small arrow in its bottom-right corner to jump to the related page.
Why don't I get emails when teammates join or change roles?
The Workspace activity category defaults to in-app only. Turn on its email toggle in Settings → Notifications (per workspace) — and pick a digest mode if you'd rather get one daily or weekly summary than an email per event.
Why is there no billing row in the preferences matrix?
Billing belongs to your account, not a workspace, so it has no per-workspace toggles. Critical notices (payment failed, card expiring, cancellation scheduled, beta ending) always reach the subscriber in-app + email; informational ones (receipts, renewals) are in-app only and never email. The only billing-adjacent workspace toggle is "Plan nudges" — the in-app hints when a workspace hits a plan limit.
Can I forward billing or product updates to Slack?
No. The channel receives source failures and workspace activity only. Billing is subscriber-only by design (your team shouldn't see your payment failures), and product updates would turn the channel into a changelog feed.
Our Slack messages stopped arriving. What happened?
Most likely the webhook URL was revoked or the Slack app removed — channel delivery is best-effort and fails silently rather than blocking your notifications. Regenerate the webhook in Slack, open Settings → Notifications → External delivery → Change, paste the new URL, and click Test to confirm.