Allow setting a different priority for resolved ntfy notifications

[cad0p]

Summary

The ntfy provider uses a single priority for both triggered and resolved messages: buildRequestBody in alerting/provider/ntfy/ntfy.go always sends cfg.Priority. Pushover supports a separate resolved-priority (#879, requested in #767); the same would be useful for ntfy.

Use case: a critical endpoint wants priority: 5 (max) when it fails, but the resolved message should be quiet (e.g. priority: 3) instead of bypassing DND a second time. Today the choices are repeating the trigger priority on resolve or setting send-on-resolved: false and getting no recovery notification at all.

Proposed configuration

alerting:
  ntfy:
    url: "https://ntfy.sh"
    topic: "..."
    priority: 5            # triggered
    resolved-priority: 3   # resolved; defaults to `priority` when unset

Proposal

• Add resolved-priority (int, optional) to the ntfy Config, matching Pushover's field name (resolved-priority / ResolvedPriority).
• When set, valid range is 1–5, same as priority; 0 means unset.
• When unset, resolved messages use priority (not the provider default of 3), which keeps existing configs backward compatible.
• Merge(): apply a non-zero override like the other fields, so group overrides and alert-level provider-override keep working.
• buildRequestBody(): when resolved == true, send resolved-priority if set, otherwise fall back to priority.
• Apply the fallback after overrides are merged, so an override that only sets priority also affects resolved messages when resolved-priority was never set.

Alternatives

The custom provider can express this today with the [ALERT_TRIGGERED_OR_RESOLVED] placeholder, but that requires hand-rolling the ntfy JSON payload instead of using the native provider.

Happy to open a PR if the approach looks right.

[wahajahmed010]

Read through the proposal and the existing Pushover implementation (alerting/provider/pushover/pushover.go). The design lines up cleanly with what Pushover already does, with one important edge case worth pinning down before you open the PR.

Looks good

• Field name resolved-priority / ResolvedPriority matches Pushover exactly — consistent across providers. ✓
• Range validation 1–5 mirrors the existing priority validation in Validate(). ✓
• Merge() with override.ResolvedPriority > 0 follows the same non-zero-truthy pattern ntfy already uses for Priority (line 56). ✓
• Sending cfg.ResolvedPriority if set, else falling back to cfg.Priority, is the right semantics.

Edge case to confirm

Pushover's Validate() does this at line 65:

if cfg.ResolvedPriority == 0 {
    cfg.ResolvedPriority = defaultPriority   // 0
}

For Pushover, 0 is the default, so this is a no-op. For ntfy, 0 is the unset sentinel — and Validate() currently does:

if cfg.Priority == 0 {
    cfg.Priority = DefaultPriority   // 3
}

If you copy Pushover's pattern verbatim for ResolvedPriority, you'll silently coerce an explicit resolved-priority: 0 (which ntfy can't actually take per range, but 0 will be the Go zero value) into 3 during validation — that's probably fine since ntfy rejects < 1, but worth a one-line code comment so a future reader doesn't think 0 is a valid override.

Implementation order subtle

You wrote: "Apply the fallback after overrides are merged, so an override that only sets priority also affects resolved messages when resolved-priority was never set."

Right — the current Merge() runs before Validate(), and Validate() is what defaults Priority to 3. So the order has to be:

1. GetConfig → cfg.Merge(groupOverride) → cfg.Merge(providerOverride)
2. In buildRequestBody, pick resolved ? cfg.ResolvedPriority : cfg.Priority
3. Then Validate() runs (it's called inside GetConfig after merges) and defaults Priority to 3 if still 0.

That sequence already matches the existing ntfy flow — no reordering needed.

Minor: tests

Worth adding:

• resolved-priority: 1 with priority: 5 → trigger body has "Priority": 5, resolve body has "Priority": 1.
• resolved-priority unset with priority: 5 → both bodies have "Priority": 5 (backward compat).
• resolved-priority: 6 → validation error (mirrors existing range check).
• Group-override-only: override block sets resolved-priority: 2 → resolve body uses 2.

The existing pushover_test.go round-trip pattern is a good template.

Overall the proposal is implementation-ready; opening the PR against master looks straightforward.