Skip to main content

Deprecations and EOL policy

Features, fields and UI items marked deprecated, with their replacements; the project publishes no removal schedule, and GitHub releases are the version record.

This page lists what Nightingale marks as deprecated and what replaced it. It does not list removal dates, because the project does not publish any — see the first section before reading the rest.

There is no published maintenance policy​

The project publishes no support matrix, no LTS designation, no stated maintenance window per minor version, and no announced removal schedule for anything on this page. Compatibility matrix says the same thing about platform versions, for the same reason.

In practice the head of the release line is what receives fixes: v9.1.1 is a patch on top of v9.1.0, and that is where a bug fix appears. Beyond that, the authoritative record is GitHub:

What you want to knowWhere
Which versions exist, and when each was releasedGitHub Releases
Whether a fix has landedThe fix: entries in each release — see Release notes
Whether a field is still read by the engineThe source. Nothing else is binding

Everything marked deprecated below still exists and still works in v9.1.1. Nothing has been removed. Read "deprecated" as "the replacement is where new work should go", not as "this stops working next release" — nobody has said when, and you should not infer a date from this page.

The install date decides what you still see​

The interface hides deprecated menu entries based on when the installation was created, not which version it runs. The cutoff is 2025-06-20, the v8 beta 14 release:

  • an installation created after that date never shows the deprecated notification pages, and never shows the notification-version switch on the alert rule form;
  • an installation created before it still shows them, with a deprecation marker beside them in the sidebar.

So two systems both running v9.1.1 can have different menus, and neither is broken. If a colleague's install has entries yours does not, theirs predates the cutoff.

Deprecated in the interface​

WhatWhere it wasReplacement
Notification (/help/notification-settings)Alerts & NotificationsNotification rules plus Media types
Templates (/help/notification-tpls)Alerts & NotificationsMessage templates
Relabel, on the alert rule formThe alert rule formThe Event label rewrite processor in an event-processing workflow

The first two are the entries hidden by the install-date rule above. The third is not hidden — the form carries its own notice saying that existing relabel configuration is better expressed as a workflow processor.

Deprecated fields on the alert rule​

These carry a Deprecated marker in the alert rule model. All of them are still accepted and still returned by the API:

FieldReplacementNote
datasource_ids, clusterdatasource_queriesdatasource_ids is back-filled on read for the list page; the engine reads only datasource_queries
notify_channels, notify_groups, callbacksnotify_rule_idsThe three-layer notification model. A rule on notify_version: 1 does not use them
enable_stime, enable_etime, enable_days_of_weekenable_stimes, enable_etimes, enable_days_of_weeksThe singular forms held one effective window; the plural forms hold several
prom_for_durationMarked use cron pattern insteadStill the only implementation of the for-duration, and still read at every evaluation. Do not strip it from rule JSON

Anything that reads or writes alert rule JSON — an exporter, a provisioning script, a sync job — should move to the replacements, and must keep prom_for_duration regardless.

Subscription rule fields cleared by the new notification version​

Saving a subscription rule with notify_version: 1 clears these fields to empty on the server, with no error and no warning:

  • the authorised teams (user_group_ids);
  • the redefined channels (redefine_channels, new_channels);
  • the redefined webhooks (redefine_webhooks, webhooks);
  • the redefined severity (redefine_severity, new_severity).

This is intended, not a bug: on the new model those decisions belong to the notification rules the subscription selects, not to the subscription. See Alert subscriptions. If you create subscriptions from a script, sending those fields alongside notify_version: 1 silently drops them.

Code that is still there but no longer on any path​

Two things you may find by reading the source or watching a network trace. Both still respond; build on neither.

  • POST /api/n9e/busi-group/alert-rules/notify-tryrun and .../enable-tryrun. The frontend still defines a wrapper for each, and its only call sites for them are commented out. Their job is done by test fire, which walks query → threshold → event → notification in one pass instead of two partial checks.
  • The v7-era senders in alert/sender/ (DingTalk, WeCom, Feishu, Lark, Telegram, Mattermost, email). They are still compiled in and still wired up, but only the legacy path reaches them: an event from a rule on notify_version: 0 carrying notify_channels and notify_groups. Notification rules take an entirely different route, through the media types configured under Alerts & Notifications → Media types. Editing a template on the old path does not change what notification rules send.

On this page