Releases: appwrite/grafana-oncall
Release list
v1.22.2
Labels and annotations on a card sit under a heading each, as bullets, with values in inline code:
[production] ArgoCD application cloud-operators/cloud-tor1-prod-monitoring has been Progressing for over 15 minutes.
A sync that never settles is almost always a workload that never becomes Ready.
**Labels**
- name: `cloud-tor1-prod-monitoring`
- deployment_environment_name: `production`
- project: `cloud-operators`
- team: `cloud`
**Annotations**
- datasource_uid: `PBFA97CFB590B2093`
- grafana_state_reason: `NoData`
- ref_id: `A`
v1.22.0 and v1.22.1 printed these as plain lines, with nothing marking where the alert's own text ended.
The same keys are kept and the same duplicates dropped as before.
Values that would break the formatting
A value is the sender's text, so it can contain a newline or a backtick. A newline used to split its bullet across two lines, and a backtick closed the inline code span early, formatting the rest of the card as code.
- Whitespace in a value is collapsed, so one entry stays one bullet.
- A value containing a backtick is printed without the code span, rather than being altered to fit it.
Full Changelog: v1.22.1...v1.22.2
v1.22.1
Grafana wraps its own identifiers in double underscores and sends them as labels as well as annotations. v1.22.0 excluded the annotations, so a card still carried them as label lines:
name: backups-tor
__alert_rule_namespace_uid__: terraform-alerts
__alert_rule_uid__: afsxq6b2qb85cb
cluster: assets-fra1-prod
Labels now follow the same rule as annotations. A card for a Grafana managed alert is 3 lines shorter.
The test payload for these templates was written from a card captured before Grafana adopted the reserved naming, so it used alert_rule_uid, orgId, values and value_string without underscores. It is now taken from a live payload. Plain names remain handled for senders that use them.
Full Changelog: v1.22.0...v1.22.1
v1.22.0
Discord templates for Alertmanager and Grafana Alerting
A card rendered from an Alertmanager alert was 29 lines, because there were no discord_* templates and the templater falls back to the web templates, which list every label and annotation under three headings.
The same alert now renders as:
Synthetic test failed two consecutive runs.
name: backups-tor
alert_rule_uid: afsxq6b2qb85cb
cluster: assets-fra1-prod
kind: PlaywrightTest
service: backups
team: databases
orgId: 1
values: {"A":0,"B":0,"C":0}
Every label and annotation is kept, one per line, with its name. No label name is special cased. What is removed is only what appears elsewhere:
| removed | shown instead |
|---|---|
alertname |
the card title |
severity |
the title emoji and the forum tag |
value_string |
values, when the payload has one |
| a key present in both labels and annotations | printed once |
__dashboardUid__, __panelId__ |
reserved by Grafana and hidden in its own UI |
dashboard_url, dashboardURL |
the Dashboard button |
Severity: and Status: lines |
the title emoji and the timeline |
Legacy payloads that carry labels and annotations at the top level are read as well. A rule that sets both a summary and a description shows both.
Backend specific template defaults
get_default_template_attribute sent every extra messaging backend to the web templates. It now uses a backend's own template when the integration defines one and falls back to web otherwise, so Mattermost is unaffected. Any backend can define templates by adding <backend>_<attr> to an integration config.
Only alertmanager and grafana_alerting define Discord templates. Other integrations keep their web templates.
Source and Dashboard buttons
The source link button was labelled Dashboard for the Grafana and Alertmanager integrations. For a Grafana managed rule that link opens the rule, not a dashboard.
- The source link button is labelled
Source. - A dashboard link found in
dashboard_urlordashboardURL, in either the common or top level annotations, gets aDashboardbutton. - Both appear only when the two links differ.
Full Changelog: v1.21.4...v1.22.0
v1.21.4
The Timeline field's first line showed the severity emoji while the other lines showed status emoji:
🚨 Fired 13:13 (3 hours ago)
🟡 Acknowledged by someone 13:16
✅ Resolved by alert source 15:54
It now shows the firing status emoji, which matches the forum tag:
🔥 Fired / 🟡 Acknowledged / 🔕 Silenced / ✅ Resolved
Severity is unchanged elsewhere. It still leads the card's title, so a critical alert group is titled 🚨 … with 🔥 Fired in its timeline.
Full Changelog: v1.21.3...v1.21.4
v1.21.3
Required if an escalation chain ends in a step that notifies the whole channel.
That step was rejected for any organization without Slack:
POST /api/v1/escalation_policies/
400 {"detail": "Invalid escalation step type: step is Slack-specific"}
Slack was the only integration that could serve the step when it was added. The Discord integration serves it as well, so the check is now whether any connected chat integration can act on it. A chain ending in that step can be provisioned through the public API and configured in the UI by a Discord-only organization.
Two limits are unchanged:
- The user group steps still require Slack. They point at a Slack user group, and the task serving them returns early without a Slack team identity.
- Escalating no longer returns without posting when a route names no Discord role. A route may or may not name one, which is not known when the step is added to a chain, so the message is always posted. The role is mentioned when the route names one.
Full Changelog: v1.21.2...v1.21.3
v1.21.2
Forum tags are matched per word
A tag named ℹ️ Info did not match Info, so it was never applied. ℹ is U+2139 INFORMATION SOURCE, which Unicode classifies as a lowercase letter, so stripping non-letters left it attached to the word. The variation selector that marks emoji presentation would distinguish it, but Discord removes that when storing a tag name.
Tag names are now read one word at a time. An emoji, a grouping label or a priority prefix is a separate word, so P1 Critical matches as well. Only whole words match, so Informational matches nothing.
Info severity uses 📘
Cards, the route editor and the docs use 📘 for info severity instead of ℹ️, so a tag named after the card's emoji works.
No re-connection is needed. Matching runs against the tag list already stored for the channel.
Full Changelog: v1.21.1...v1.21.2
v1.21.1
Fixes on-call notifications and shift announcements in forum channels. Required if you use forum channels.
A follow-up to a card, either the mention from a user's notification policy or a shift start announcement, was addressed to the forum channel instead of the post. Discord rejects that:
POST /channels/{forum_id}/messages
400 {"message": "Cannot send messages in a non-text channel", "code": 50008}
notify_by=DISCORD in a notification policy therefore never arrived, and because 400 is not in the set of statuses the task treats as final, it retried indefinitely.
Follow-ups are now posted into the post. In a text channel they still quote the card, so they read as a reply. Inside a post there is nothing to quote, because the post is the card. A shift announcement has no card to attach to, so in a forum channel it opens a post.
Full Changelog: v1.21.0...v1.21.1
v1.21.0
Forum tags for status and severity
Where a forum has tags with these names, a post is tagged with its status and its severity, and the tags are kept current:
Firing Acknowledged Silenced Resolved
Critical Warning Info
Decoration around the name is ignored, so 🔥 Firing, Resolved ✅ and Status: 🔥 Firing all match the firing status. Tags that do not exist are not applied. A forum with only status tags behaves as it did before.
Severity renamed
A route's severity was alert or warning. It is now critical, warning or info, matching the values used in alerting labels. A firing card reads by its severity (🚨 red,
MSG91 SMS provider
A phone provider for MSG91, selected with PHONE_PROVIDER=msg91 and configured by MSG91_AUTH_KEY, MSG91_SENDER_ID and MSG91_TEMPLATE_ID. These are live settings, so they can be corrected in Settings without a restart.
SMS only. MSG91 has no calls and no verification service, so the verification code is generated and checked by OnCall. The flow template must be registered with a single variable named content or otp, which receives the message text.
Upgrading
No migration is required. A route saved as warning still means warning. A route saved as alert reads as critical, which is what it meant, so rendering does not change. The route editor shows critical for such a route and writes critical the next time the route is saved.
A forum set up against an earlier version has a tag named Alert, which no longer matches anything. Rename it to Firing or Critical, then re-connect the channel. Until then its posts keep the tag they were last given, because an unmatched name leaves a post's tags alone rather than clearing them.
Full Changelog: v1.20.0...v1.21.0
v1.20.0
Adds Discord as a messaging backend. OnCall posts alert groups to Discord, handles the button presses, and notifies users through their notification policies, in the same way as the Slack and Mattermost integrations.
Configuration
FEATURE_DISCORD_INTEGRATION_ENABLED=True
DISCORD_BOT_TOKEN=<bot token>
DISCORD_PUBLIC_KEY=<application public key>
CELERY_WORKER_QUEUE=...,discord
Set the application's Interactions Endpoint URL to /api/internal/v1/discord/interaction. Nothing is posted until a channel is connected under Settings, ChatOps, Discord.
The card
- Title, message, image and source link from the alert, with emoji shortcodes expanded and a masked link with no target reduced to its label.
- Buttons for acknowledge, resolve, add note, a link to OnCall, and a link to the alert source when it has one.
- A silence menu of durations, a menu to page a responder, and a modal for a resolution note.
- A Timeline field using Discord timestamps, so each reader sees their own clock.
- A footer with the integration name, the alert group number, and the number of alerts in the group.
Forum channels
Connecting a forum channel makes each alert group a post instead of a message in a shared channel. Posts are tagged with the group's state where the forum has tags with matching names. OnCall unarchives a post before editing it, because Discord rejects edits to an archived post.
On retry, an existing post is identified by the custom_id its buttons carry rather than by its name, so two alerts with similar titles are not confused.
Routing
- A route selects the Discord channel its alert groups are posted to.
- A route selects whether its alert groups read as an alert or a warning.
- A route can name a Discord role, mentioned when escalation reaches a step that notifies everyone.
- Shift starts are announced in the default channel.
Linking accounts
Users run /oncall-link in Discord, or use the Discord tab of their OnCall profile. A linked user can be mentioned by escalation and can use the card's buttons. An unlinked user is named in the message but not mentioned.
Full Changelog: v1.19.1...v1.20.0
v1.19.1
Each release now attaches grafana-oncall-app-<version>.zip and grafana-oncall-app-<version>.zip.sha256.
This allows a deployment to install the frontend by version and verify it by checksum, instead of building it or taking it from a catalog. Upstream's catalog build is frozen at 1.16.11.
No engine or plugin behaviour changes.
Full Changelog: v1.19.0...v1.19.1