Rendering notification templates should not silently swallow errors

Proposal

Notifications templates are configured to silently swallow the errors and passing the final output, including the rendering error, to the underlying notification handler.

Depending on the notification handler, this may or may not work and errors may be reported in a very difficult way to investigate.

For instance, the Slack notifier accepts several configuration fields as Go templates. If one of the template fails to render, the error is ignored and the result sent to the Slack API, which may fail to process the message and fails with:

time=2026-06-23T15:14:49.930Z level=ERROR source=dispatch.go:611 msg="Notify for alerts failed" component=dispatcher aggrGroup="..." num_alerts=1 err="alerts/slack[0]: notify retry canceled due to unrecoverable error after 1 attempts: channel "": error response from Slack: invalid_arguments"

You then have to go through all the templates and find out which one was failing.

It would be much more resilient instead to:

1. Log errors when templates are failing to render
2. Not even try to call the notification handler if a related template fails to render

In my case, amtool template render correctly reports the problem so it could have been identified earlier, but as formatting can also be highly dependent on the alerts themselves, it may be difficult to achieve 100% test coverage ahead of time and not being able the actual error makes it really difficult to find out what the problem is.

Related:

• https://github.com/prometheus/alertmanager/issues/3490

Start by tracing notification template rendering from the notification path and compare it with the behavior of amtool template render; the issue does not name specific source files or tests. Done means template rendering errors are logged and the notification handler is not called when a related template fails.