CoreComms
Multi-channel notification routing with priority filtering and delivery tracking.
Tier: Standard | Price: $5 one-time
Overview
CoreComms is a notification routing plugin for QuoxCORE. It delivers alerts across five channel types -- Telegram, Slack, Email, Discord, and generic webhooks -- with per-channel priority filtering, automatic retry with exponential backoff, and a full delivery log.
Configure the channels your team actually uses, assign priority thresholds, and let CoreComms handle delivery. If a channel fails repeatedly, the plugin disables it automatically to prevent alert storms. Every message is logged with delivery status, timing, and retry count.
Channels
CoreComms supports five channel types. Each channel is configured independently and can be enabled or disabled without affecting the others.
Telegram
Connect one or more Telegram bots to receive notifications in group chats or direct messages.
- Create a bot via @BotFather and copy the bot token.
- Add the bot to your target group or start a direct conversation with it.
- Enter the bot token and chat ID in the channel configuration panel.
- Multi-bot support: add several Telegram channels with different bots for different teams or severity levels.
Slack
Send formatted notifications to Slack channels using incoming webhooks.
- Create an incoming webhook in your Slack workspace (Apps > Incoming Webhooks).
- Paste the webhook URL into the channel configuration.
- Messages arrive with rich formatting: priority badge, source context, and timestamp.
- Each webhook targets a single Slack channel. Add multiple Slack channels in CoreComms to route to different rooms.
Email (SMTP)
Deliver notifications as email messages through any SMTP provider.
- Supported providers include Gmail, Outlook, and SendGrid. Any standards-compliant SMTP server works.
- Configure the SMTP host, port, username, and password (or app-specific password for Gmail).
- Set one or more recipient addresses per channel entry.
- TLS is enabled by default. For providers requiring STARTTLS, select that option in the configuration panel.
Discord
Post notifications to Discord channels via inbound webhooks.
- In your Discord server, go to Channel Settings > Integrations > Webhooks and create a new webhook.
- Copy the webhook URL and paste it into the CoreComms channel configuration.
- Messages include an embed with priority colour coding, source details, and timestamp.
Generic Webhooks
Send notification payloads to any HTTP endpoint. This covers services like PagerDuty, Opsgenie, or custom internal systems.
- Enter the target URL.
- Optionally set custom headers (e.g.
Authorization: Bearer <token>). - The payload is a JSON object containing the notification body, priority level, timestamp, and source metadata.
- The endpoint must return a 2xx status code for delivery to count as successful.
Priority Filtering
Each channel has an independent priority threshold. Notifications below that threshold are not sent to the channel.
Four priority levels are available:
| Priority | Use case |
|---|---|
| Critical | Service outages, security alerts, data loss events |
| High | Degraded performance, failed deployments, SLA warnings |
| Medium | Routine operational notices, scheduled tasks completing |
| Low | Informational updates, non-urgent status changes |
Set the threshold in the channel configuration panel. For example, a Telegram channel set to "High" receives only high and critical notifications. A Slack channel set to "Low" receives everything.
This lets you keep noisy low-priority traffic in a broad channel (email digest, general Slack room) while directing critical alerts to focused channels (on-call Telegram bot, PagerDuty webhook).
Reliability
CoreComms is built to handle transient failures without losing notifications or flooding broken channels.
Exponential Backoff
When a delivery attempt fails, CoreComms retries with exponential backoff. The wait time doubles after each failed attempt:
| Attempt | Wait before retry |
|---|---|
| 1st retry | 2 seconds |
| 2nd retry | 4 seconds |
| 3rd retry | 8 seconds |
| 4th retry | 16 seconds |
| 5th retry | 32 seconds |
After five consecutive failures for a single message, the delivery is marked as failed in the log.
Auto-Disable
If a channel accumulates repeated failures across multiple messages, CoreComms disables the channel automatically. This prevents alert storms where hundreds of retries pile up against a dead endpoint.
A disabled channel appears with a warning badge in the configuration panel. Re-enable it manually after resolving the underlying issue (expired token, unreachable endpoint, revoked webhook). Use the test connection button to verify the channel works before re-enabling.
Test Connection
Every channel type has a "Test Connection" button that sends a test notification through the configured endpoint. Run this after initial setup and after any credential changes. The test result shows success or the specific error returned by the remote service.
Routing Rules
The routing rules panel controls which notifications go where, beyond simple priority filtering.
Organisation and Team Scope
Assign channels to specific organisations or teams. A channel scoped to "Engineering" only receives notifications originating from that team's context. Unscoped channels receive notifications from all sources.
Custom Rules
Build rules that match on notification attributes:
- Source -- Match by the plugin or system that generated the notification.
- Priority -- Override the default channel threshold for specific sources.
- Keyword -- Match notifications containing specific terms in the subject or body.
Rules are evaluated in order. The first matching rule determines the channel set. If no rules match, the default routing (all enabled channels at or above their priority threshold) applies.
Delivery Log
Every notification attempt is recorded in the delivery log. The log is accessible from the CoreComms plugin panel.
Log Fields
| Field | Description |
|---|---|
| Timestamp | When the notification was sent |
| Channel | Which channel received the delivery attempt |
| Priority | The priority level of the notification |
| Status | Delivered, failed, or pending retry |
| Retry count | Number of delivery attempts for this message |
| Latency | Time from send to confirmed delivery |
Analytics
The log panel includes summary analytics:
- Delivery rate -- Percentage of notifications successfully delivered on the first attempt.
- Channel breakdown -- Volume and success rate per channel.
- Priority distribution -- How many notifications at each priority level over a selected time range.
- Failure trends -- Channels with rising failure rates, highlighted before they trigger auto-disable.
Filter the log by date range, channel, priority, or status. Export as CSV for external analysis.
Inbox Integration
Notifications also appear in the QuoxCORE inbox. The inbox provides a unified view across all plugins, with CoreComms entries linking back to the full delivery log entry for that message.
Configuration
Required Credentials by Channel
| Channel | Required fields |
|---|---|
| Telegram | Bot token, chat ID |
| Slack | Incoming webhook URL |
| SMTP host, port, username, password, recipient(s) | |
| Discord | Webhook URL |
| Generic webhook | Endpoint URL, optional headers |
All credentials are stored encrypted. They are never exposed in logs or API responses.
Settings
| Setting | Default | Description |
|---|---|---|
| Max retries | 5 | Maximum delivery attempts per message |
| Auto-disable threshold | 10 | Consecutive failures before a channel is disabled |
| Default priority | Medium | Priority assigned when the source does not specify one |
| Log retention | 30 days | How long delivery log entries are kept |
Adjust these in the CoreComms settings tab. Changes take effect immediately for new notifications. In-flight retries continue with their original settings.