feat(ntfy): add custom title and message templates for notifications

[epifeny]

Add optional custom templates for ntfy notification titles and messages using the existing LiquidJS templating system. Supports both notification-level templates (in ntfy settings) and per-monitor overrides (in monitor edit page).

• Notification-level templates in ntfy notification settings
• Per-monitor template overrides in monitor edit page
• Uses existing renderTemplate() with LiquidJS
• Priority: monitor-level > notification-level > default format
• Backward compatible: empty templates use default Uptime Kuma format
• Database migration adds ntfy_custom_title and ntfy_custom_message to monitor table
• Notification-level templates stored in JSON config field (no schema change needed)

Related: #6797

Summary

In this pull request, the following changes are made:

This adds optional custom templates for ntfy notification titles and messages. Users can set a custom title and message in the ntfy notification settings, and optionally override them per monitor on the edit monitor page. Both use the existing LiquidJS templating system, so it fits the approach in #646.

Related to feature request #6797

• Relates to Adding templating to more notification providers #646
• Resolves Custom template for ntfy (or any service provider?) #6797

Please follow this checklist to avoid unnecessary back and forth (click to expand)

• ⚠️ If there are Breaking change (a fix or feature that alters existing functionality in a way that could cause issues) I have called them out
• 🧠 I have disclosed any use of LLMs/AI in this contribution and reviewed all generated content.
  I understand that I am responsible for and able to explain every line of code I submit.
• 🔍 Any UI changes adhere to visual style of this project.
• 🛠️ I have self-reviewed and self-tested my code to ensure it works as expected.
• 📝 I have commented my code, especially in hard-to-understand areas (e.g., using JSDoc for methods).
• 🤖 I added or updated automated tests where appropriate.
• 📄 Documentation updates are included (if applicable).
• [] 🧰 Dependency updates are listed and explained.
• ⚠️ CI passes and is green.

Screenshots for Visual Changes

Notification service edit page

Default collapsed (when both input fields are empty) toggler

Expanded toggler

Monitor type edit page

Default collapsed (when both input fields are empty) toggler

Expanded toggler

These are pretty self-explanatory I hope

To get the Group "phones" message, I used this title:

📱 {{ name }} - {{ status }}

and message:

{% if status == "✅ Up" %}
✅ All {{ monitorJSON.childrenIDs | size }} phones are operational!
{% elsif status == "🔴 Down" %}
{% assign cleanMsg = msg | replace: "[phones] [🔴 Down] ", "" %}
{% assign downPart = cleanMsg | split: "Child monitors down: " | last | split: ";" | first %}
{% assign downMonitors = downPart | split: ", " %}
{% assign downCount = downMonitors | size %}
{% assign totalCount = monitorJSON.childrenIDs | size %}
{% if downCount == 1 %}
⚠️ 1 out of {{ totalCount }} phones is down
{% else %}
⚠️ {{ downCount }} out of {{ totalCount }} phones are down
{% endif %}
Down: {{ downPart }}
{% else %}
{% assign cleanMsg = msg | replace: "[phones] ", "" | replace: "[⏳ Pending] ", "" %}
⏳ {{ cleanMsg }}

Monitoring {{ monitorJSON.childrenIDs | size }} phones
{% endif %}

[CommanderStorm]

Contains a bunch of unrelated changes that I would like to see removed, but once they are LGTM.

[CommanderStorm]

Please use the components that the other notification providers use for this

[epifeny]

I'm not sure if I'm suppose to respond here and "resolve conversation", but I've updated the code and the PR, so you can review it now.

[epifeny]

Contains a bunch of unrelated changes that I would like to see removed, but once they are LGTM.

Thank you for taking the time to review my PR.
I read, and to my best understanding, you would like me to completely remove my feature of allowing per-monitor notification override to the notification service provider, which was a substantial part of the PR in the first place.
It's a feature I would like to introduce, if not as a core idea to all monitors types and notification service in uptime kuma, at the very least, as per my current PR provides, to the NTFY provider.
Why would you not want it?

[CommanderStorm]

Tangling monitor and notification logic is very hard to maintain/reason about and I don't think this is a good idea.
Please remove this part.

Notifications can still be templated differently for some monitors, just via different notification configurations, not what you are trying to add.

[epifeny]

Again, thanks for the response. I've made the changes you asked for.

Tangling monitor and notification logic is very hard to maintain/reason about and I don't think this is a good idea. Please remove this part.

In efforts to learn and understand more, please, can you explain why?

Notifications can still be templated differently for some monitors, just via different notification configurations, not what you are trying to add.

Yea, I got it working with some advanced conditional templates, like this
title

{%- if status contains "Up" -%} {{ name }} Up {%- elsif status contains "Down" -%} {{ name }} Down {%- else -%} {{ name }} {{ status }} {%- endif -%}

message

{%- comment -%} Determine alert level {%- endcomment -%}
{%- assign alert_level = "INFO" -%}
{%- assign should_escalate = false -%}

{%- if status contains "Down" -%}
  {%- assign alert_level = "WARNING" -%}
  
  {%- if name contains "epifeny" or name contains "critical" -%}
    {%- assign alert_level = "CRITICAL" -%}
    {%- assign should_escalate = true -%}
  {%- endif -%}
  
  {%- for tag in monitorJSON.tags -%}
    {%- if tag.name == "phone" and tag.value contains "fbal" -%}
      {%- assign alert_level = "CRITICAL" -%}
      {%- assign should_escalate = true -%}
    {%- endif -%}
  {%- endfor -%}
{%- endif -%}

{%- if alert_level == "CRITICAL" -%}
🚨 PHONE-FBAL ALERT 🚨
=========================
{%- elsif alert_level == "WARNING" -%}
⚠️ WARNING
=========================
{%- else -%}
ℹ️ INFO
{%- endif %}

Monitor: {{ name }}
Status: {{ status }}
{%- if monitorJSON.type != "ping" and msg -%}
Message: {{ msg }}
{%- endif -%}

{%- comment -%} Only show URL if it's not empty or default {%- endcomment -%}
{%- if monitorJSON.url and monitorJSON.url != "https://" and monitorJSON.url != "" %}
URL: {{ monitorJSON.url }}
{%- endif -%}

{%- if should_escalate %}
⚠️ IMMEDIATE ATTENTION REQUIRED
{%- endif -%}

[CommanderStorm]

In efforts to learn and understand more, please, can you explain why

If you have roughly two systems in the codebase and then they start interacting like you have shown this just is very hard to maintain long term.
We want to have low coupling and high cohesion, coupling these systems like proposed is not a good idea.

Notification templating yes, per monitor notification template no

[epifeny]

I see that you marked this PR as draft. Is there anything else that was required from me that I didn't do?

[CommanderStorm]

Yes, the PR does not quite seem done.

It contains a few changes which are leftover from previous versions (such as changing the toggler) and the frontend does not yet use the components we have for adding templatable inputs.

It is still a draft.

[epifeny]

Ok, if you could point out what I missed, I'll fix it.

[CommanderStorm]

I thing the unrelated changes should be clear and where to use TemplatedTextarea and TemplatedInput instead should also be relatively clear.

I don't quite understand where what I posted is unclear.

[epifeny]

Hello,

I'm sorry, I'm just trying to do my best, and this is really just my very 2nd pull request (ever, for any project anywhere), so I want to do the right thing and to do it right (code wise). I'm not a developer, but I can probably do some things correctly. Your guideness is very important to me.

so i updated the code to use TemplatedInput and TemplatedTextarea like you asked. but i noticed something - since ntfy has two inputs (title and message), the helper text about liquidjs templating shows up twice now (once above each input).

i checked and saw that smtp does the same thing (it has subject and body, both use the templated components, so helper text shows twice there too). so i'm wondering - is this the expected behavior? or should we do something different for providers that have multiple templatable inputs?

i can see telegram only has one input so it's fine there, but for ntfy with two inputs it does feel a bit redundant. let me know what you'd prefer!

here you can see the ntfy with your changes in-place

and smtp has this, what i consider, redundancy

but for telegram, this isn't an issue

[CommanderStorm]

LGTM now, thanks ❤️

I am fine with being a bit verbose in the UI if this checkbox is ticked.
It is not the default anyhow 👍🏻

[Copilot]

Pull request overview

Adds optional Liquid-based templating for ntfy notification titles and messages, configurable from the ntfy notification settings UI and applied server-side when sending ntfy notifications.

Changes:

• Updated English i18n strings for templating help text and new ntfy template UI labels.
• Added ntfy notification settings UI to enable/disable templates and edit custom title/message templates.
• Implemented server-side template rendering for ntfy title/message when templates are enabled.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/lang/en.json	Adds new ntfy template-related strings and adjusts the general Liquid introduction text.
src/components/notifications/Ntfy.vue	Adds template toggle plus custom title/message template inputs to the ntfy notification editor UI.
server/notification-providers/ntfy.js	Applies renderTemplate() to title/message when ntfyUseTemplate is enabled.

[Copilot]

The updated liquidIntroduction string no longer introduces the variable list, but TemplatedInput.vue/TemplatedTextarea.vue still render the variables directly beneath it, which makes the UI read abruptly. Also, the newly added keys templateAvailableVariables, example, and Result are not referenced anywhere in src/ (verified via search), so they appear to be dead translations. Consider either wiring these keys into the templated input components (e.g., add headings/labels) or removing them and restoring the original introduction text.

Suggested change

	"liquidIntroduction": "Templatability is achieved via the Liquid templating language. Please refer to the {0} for usage instructions.",
	"templateAvailableVariables": "Available variables",
	"example": "Example",
	"Result": "Result",
	"liquidIntroduction": "Templatability is achieved via the Liquid templating language. The following variables are available; please refer to the {0} for full usage instructions.",

[Copilot]

The PR description mentions per-monitor template overrides and a database migration adding ntfy_custom_title/ntfy_custom_message, plus a precedence order (monitor-level > notification-level > default). In the current changes, only notification-level fields (ntfyUseTemplate, ntfyCustomTitle, ntfyCustomMessage) are implemented and there are no monitor-level fields/migrations in the codebase (verified via repo search). Please either implement the missing monitor-level behavior/migration or update the PR description and linked issue resolution accordingly.

[Copilot]

The custom template rendering logic is duplicated between the heartbeatJSON == null path and the normal heartbeat path. To reduce the chance of future drift (e.g., updating trimming rules or adding new context variables in only one branch), consider extracting a small helper that applies templates and returns the final title/message.

[epifeny]

LGTM now, thanks ❤️

I am fine with being a bit verbose in the UI if this checkbox is ticked. It is not the default anyhow 👍🏻

Thank you for the explanations and assistance and ofc, for the merge :) cheers