notify: Adds support for gotify open-source notification service.

[TheSp1der]

Summary

This PR adds a new Gotify receiver integration.

• Adds notify/gotify notifier implementation using Gotify’s /message API with X-Gotify-Key authentication.
• Adds gotify_configs to the Alertmanager configuration and wires it into receiver integration building.
• Adds default templates for gotify.default.title and gotify.default.message.
• Includes unit tests covering:
  • JSON payload formatting and headers.
  • Optional extras.client::display.contentType for markdown delivery.
  • Reading URL and token from files and ensuring secrets are not leaked in errors.

Pull Request Checklist

• Please list all open issue(s) discussed with maintainers related to this change
  • Fixes Feature suggestion: Add Gotify as receiver #2120
• Is this a new Receiver integration?
  • I have already tried to use the Webhook Receiver Integration and 3rd party integrations before adding this new Receiver Integration.
  • I'm submitting this because I want this integration to be easy for Gotify. It's a great project with over 44 million docker pulls. It's actively maintained and adding an easy integration support is a win for Prometheus/Alertmanager.
• Is this a bugfix?
  • No.
• Is this a new feature?
  • I have added tests that test the new feature's functionality
• Does this change affect performance?
  • Benchmarks not required. See comments below.
• Is this a breaking change?
  • My changes do not break the existing cluster messages
  • My changes do not break the existing api
• I have added/updated the required documentation
• I have signed-off my commits
• I will follow best practices for contributing to this project

Which user-facing changes does this PR introduce?

[FEATURE] Notify: Add Gotify receiver integration.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This PR adds Gotify as an Alertmanager notification receiver, including configuration validation, receiver integration wiring, HTTP delivery, default templates, and tests for payloads, content metadata, and file-based secrets.

Changes

Gotify Receiver Support

Layer / File(s)	Summary
Gotify config schema and validation notify/gotify/config.go, notify/gotify/config_test.go, config/config.go	Defines GotifyConfig defaults and validation, adds Receiver.GotifyConfigs, and propagates HTTP configuration during loading.
Receiver integration wiring config/receiver/receiver.go	Constructs and registers Gotify notifiers for configured receiver entries.
Notifier implementation, templates, and tests notify/gotify/gotify.go, notify/gotify/gotify_test.go, template/default.tmpl	Renders Gotify notifications, posts JSON payloads with authentication, supports content metadata and file-based secrets, and adds default title/message templates.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Alertmanager
  participant BuildReceiverIntegrations
  participant GotifyNotifier
  participant GotifyServer
  Alertmanager->>BuildReceiverIntegrations: load GotifyConfigs
  BuildReceiverIntegrations->>GotifyNotifier: create notifier
  Alertmanager->>GotifyNotifier: Notify(alerts)
  GotifyNotifier->>GotifyServer: POST rendered JSON with X-Gotify-Key
  GotifyServer-->>GotifyNotifier: HTTP response

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR implements the requested Gotify receiver support for issue #2120.
Out of Scope Changes check	✅ Passed	The changes stay focused on Gotify receiver integration and related config, templates, and tests.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly and concisely summarizes the new Gotify notification integration.
Description check	✅ Passed	The description matches the template with summary, checklist items, issue reference, and release-notes entry.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@notify/gotify/gotify.go`:
- Line 143: The Gotify auth header is incorrectly passing the token through the
template engine, which can mutate an opaque credential and bypass template
errors already checked earlier. Update the Gotify notifier logic in the function
that builds the request header to use the raw token directly in the X-Gotify-Key
header, matching the other notifier implementations that send credentials
without templating.
- Around line 106-108: Check tmplErr before parsing priority in gotify.Notify so
template failures are not masked by strconv.Atoi. In the priority handling
block, make sure the result of tmplText(n.conf.Priority) is accompanied by an
immediate tmplErr check before calling strconv.Atoi, and return that template
error directly if present. Keep the existing priority parsing path in Notify and
the later tmplErr handling consistent, but ensure the early priority parse
cannot turn a template failure into an "invalid syntax" error.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: b8b87b8f-4049-4f3c-843b-2bd1be89a778

📥 Commits

Reviewing files that changed from the base of the PR and between 963ed72 and 9bb0878.

📒 Files selected for processing (7)

• config/config.go
• config/receiver/receiver.go
• notify/gotify/config.go
• notify/gotify/config_test.go
• notify/gotify/gotify.go
• notify/gotify/gotify_test.go
• template/default.tmpl

[TheMeier]

This looks like a simple stateles JSON post to me. So two questions:

• could this simply with a custom payload in the native webhook notifier
• why not use nofity.PostJSON()

[TheSp1der]

That's a good question:

• A webhook can approximate this, but it pushes Gotify-specific schema/auth/templating onto every user. A native receiver makes the common case safe and easy, consistent with existing receiver integrations. (Alertmanager already has receivers that do the same thing. Discord, Slack webhook mode, Incident.io, etc.)
• I didn’t use notify.PostJSON() because we need to set the X-Gotify-Key header. PostJSON currently doesn’t accept custom headers. I'm happy to update this if there’s an existing helper that supports headers, or I can add one, but that seemed out of scope for this.

[TheMeier]

That's a good question:

• A webhook can approximate this, but it pushes Gotify-specific schema/auth/templating onto every user. A native receiver makes the common case safe and easy, consistent with existing receiver integrations. (Alertmanager already has receivers that do the same thing. Discord, Slack webhook mode, Incident.io, etc.)

So the auth should be not an issue. The native webhhok supports many authentications ans cusomtizations. Especially setting a header is easy https://prometheus.io/docs/alerting/latest/configuration/#http_header
Regarding the template, a working template could be added to the default templates, docs and examples.

• I didn’t use notify.PostJSON() because we need to set the X-Gotify-Key header. PostJSON currently doesn’t accept custom headers. I'm happy to update this if there’s an existing helper that supports headers, or I can add one, but that seemed out of scope for this.

You can use a custom roundtripper to acheive that, see eg here https://github.com/prometheus/alertmanager/blob/main/notify/rocketchat/rocketchat.go#L77-L115

[TheSp1der]

I'll address the custom roundtripper as soon as I can, but I'm submitting this because I want this integration to be easy for Gotify. It's a great project with over 44 million docker pulls. It's actively maintained and adding an easy integration support is a win for Prometheus/Alertmanager.

[TheMeier]

So I quickly modelled this with the webhook:

- name: local_test
  webhook_configs:
    - send_resolved: true
      http_config:
        http_headers:
          X-Gotify-Key:
            secrets:
              - foo
      url: http://localhost:7070
      payload:
        "title": '{{ template "__subject" . }}'
        "priority": '{{ if eq .Status "firing" }}5{{ else }}0{{ end }}'
        "extras":
          "client::display":
            "contentType": "text/plain"
        "message": |
          {{ .CommonAnnotations.SortedPairs.Values | join " " }}
          {{ if gt (len .Alerts.Firing) 0 }}
          Alerts Firing:
          {{ template "__text_alert_list" .Alerts.Firing }}
          {{ end }}
          {{ if gt (len .Alerts.Resolved) 0 }}
          Alerts Resolved:
          {{ template "__text_alert_list" .Alerts.Resolved }}
          {{ end }}

The whole point of adding templating to the webhook notifier was to avoid the ever growing list of notifier integrations. It even gives users the more customization options for the actual layout of the content. (e.g. I am using webhooks instead of msteamsv2 because I can make much nicer messages that way)
In my opinion we should even remove existing integrations that are simple post-JSON style and replace them with webhook templating. Or even go back to the old stance of "use a custom middleware/adapter with the webhook". (It's just my opinion, yours might different)

There are and have been many discussions about how to deal with notification integrations and to my knowledge there is no final decision.

I will still review the code (and even approve it) but that doesn't mean it will get in (not my call).

At the moment the PR is lacking documentation updates, also whe have a PR template which points that out https://github.com/prometheus/alertmanager/blob/main/.github/pull_request_template.md as well as the webhook topic.

[TheSp1der]

@TheMeier I have added the snippet you required to the PR. I'll update the documentation and benchmark data as soon as I have a moment.

[TheMeier]

@TheSp1der IMHO benchmarking is not required here

[TheSp1der]

@TheMeier,
I have added the documentation as requested. I'm sorry I missed this. I also want to say that I respect your position on this. I know it's silly of me to say and still push for the inclusion of yet another receiver, but I'm not unfamiliar with the plight of adding things that could be done elsewhere using a different multi-purpose module. I also want to thank you for your feed back and your suggestions. Even if this PR is rejected, at least I tried. :)