@fabxc Was there a reason for this not being anchored?

I think it should be consistent.
Possible that I just didn't consider building the initial version or we made the switch to anchoring in Prometheus afterwards.

There's an obvious problem here of course. Already created silences will stop working.
So either we just accept that and break people, or we make this change to anchor on silence creation time rather than match time. That will also spawn potentially confusing results of course when old un-anchored silences have a different behavior.

@brian-brazil

I think consistency is important. In addition the same arguments about overmatching due to no anchoring as apply in PromQL&relabelling also apply here.

How this is handled UI wise is a separate question.

@brian-brazil what I mean is, we should of course change it. But this could mean that users upgrading have existing silences that will no longer match.

Probably okay when coming with a disclaimer.

Yea, we'd want to signal this clearly.

There's an obvious problem here of course. Already created silences will stop working.

I think this is more complicated - this change will either break or fix silence rules for people - depending on the intent they had when creating those, and that can easily vary from user to user in the same organisation using Prometheus.
I don't think current behavior is explicitly stated anywhere (I couldn't find anything) so it's hard to say what people assume right now, some docs on prometheus.io stating clearly what should people expect would be helpful.

I think this is more complicated

Absolutely. It should have been "will potentially stop working as before".

I will add this to 0.6.2 – potentially disruptive but as behavior was previously unspecified, it's not really a breaking change.