In short
A sequence diagram represents interactions scenario between identified instances of classes. The challenge in your question is that you want to keep it general, with an undefined number of observer instances.
There are several practices that support your need, but they rely on visual interpretation and not on semantics. A better approach would be to represent the interaction with a communication diagram, that provides more support for iterations.
P.S: You could perfectly use observer:IObserver in your diagram. Because every instance of ConcreteObserver is by definition also an instance of IObserver.
More explanations
Technique 1: Illustrative example
The diagram illustrate a concrete scenario of interactions with a finite number of observers, say 2 or 3. This requires to unroll the loop, and the iteration is only suggested by repeating the same interaction with each observer, one after the other. You may add a comment to explain the general looping logic and reinforce the idea by putting some suspension points ... here and there.
Technique 2: placeholder
This is what you did. Only a single observer instance would be used, but meant to represent the successive observers of the iteration. It should have a generic name to suggest the iterative character, such as observerN.
I'm not sure that it's legal to have a lifeline local to a fragment. I think the UML metamodel requires the lifelines to be owned by the diagram and that the loop fragment only tells if it covers the lifeline or not. It's also confusing to destroy the instance in the loop. I'd therefore reduce the width of the loop fragment in a way not to include observerN, since it's not the same observer throughout the loop.
Then it must be explained how the observer comes into play. Within the loop, you could visualise somehow that the subject gets the next observer , e.g. using an interaction that returns observerN, a message to self to get the next observer, or a comment.
You could also reinforce this semantic by adding a constraint to the lifeline { observerN is element of subject.observerList }.
Better alternative: communication diagram
The communication diagram provide a better support for iteration with a variable number of instances, via an iteration clause, that can be placed after a message sequence number. It has the format: *[iteration-clause]
UML defines it as follows:
An iteration represents a sequence of Messages at the given nesting depth. The iteration clause may be omitted (in which case the iteration conditions are unspecified). The iteration-clause is meant to be expressed in pseudocode or an actual programming language, UML does not prescribe its format. An example would be: *[i := 1..n].
Which allows you to model the communication diagram:
