Joel Baranick

As I mentioned before, this is all in the scope of reducing load again Pushover's server, so that Alertmanager is not abusing it. And as I also mentioned, I see...

Regarding Option 1, the nflog.Entry currently doesn't contain receiver specific information. I assumed, maybe incorrectly, that Alertmanager would not want to be in the business of storing receiver specific information....

@onedr0p Option 3, which is what is in the PR now, checks to see if the value `2` is anywhere within the config value for priority on the receiver. It...

> > It should be here https://github.com/prometheus/alertmanager/blob/main/nflog/nflogpb/nflog.proto#L29. > I looked there, but there is not any receiver implementation specific data at the moment and I’m not sure there should be....

> > You would add support for metadata (i.e. key/value pairs) and then each receiver could store whatever metadata it needs. No field would be added that is specific to...

@grobinson-grafana Great! That config option would let us do something like: ``` ... priority: {{ if eq .Status "firing" }}{{ if eq .CommonLabels.severity "critical" }}2{{ else }}1{{ end }}{{ else...