Getting Started

Sequence Diagram

Component: ServiceInsight

The sequence diagram shows when messages in the same conversation as the selected message were sent and handled relative to each other. It shows the interaction of endpoints involved in the conversation to give an understanding of the sequence of messages that occurred during that conversation.

Sequence Diagram

How the diagram is generated

When sending or publishing a message, NServiceBus adds identifying headers such as NServiceBus.MessageId, which is a unique ID for that message. The first message to be sent in a conversation will also get a unique ConversationId header.

If handling an incoming message results in outgoing messages, those messages are given an NServiceBus.RelatedTo header equal to the MessageId of the incoming message. They are also given the same ConversationId as the incoming message.

Additional headers are used to determine endpoint names, message intent, and other factors. Read more about headers.

The order of operations is critical to the correctness of the sequence diagram. When endpoints are running on more than one machine, it is crucial that those machines have synchronized clocks. This can be done using an NTP server.
Due to performance reasons, only the last 200 messages in a conversation are loaded. This limit can be controlled from ServiceInsight's application configuration file.

What is on the diagram

Endpoints and lifelines


Each endpoint involved in the conversation is represented by a gray box along the top of the diagram. Hover on the endpoint to get additional information, such as the host that the endpoint is running on. Extending from the bottom of each endpoint is a lifeline that shows time flowing from top to bottom.

Start of conversation

Start of conversation marker

Each conversation starts with a single command or event. This message is often triggered by some action external to the system (for example, a user clicking a Submit Order button on a website). The metadata used to generate the diagram does not include the trigger in these cases, but it does include the endpoint that sent or published the message, represented by a Start of Conversation marker on the endpoint lifeline.

The Start of Conversation marker may not always be visible. This can happen if the conversation started a long time ago and the initiating message has expired. It can also happen if the number of messages in the conversation is very large. The diagram will show only the last 50 messages from the conversation, and this may not include the initiating message.


Send message

When a message is sent, a solid arrow is drawn from the lifeline of the sending endpoint to the lifeline of the receiving endpoint, labelled with the message type. The arrow always points from the sending endpoint to the receiving endpoint.

Message context menu

Right-clicking on a message label shows actions related to that message.

Message processing box

Some time after a message is received, it is processed by the receiving endpoint. This is represented by a box on the endpoint lifeline labelled with the message type. If the endpoint received more than one message of that type, the specific message being processed may be seen by hovering over or selecting the processing box.

A message arrow shown leaving a processing box represents an outgoing message that was sent or published while processing the incoming message. These arrows are shown in the order in which those messages were sent or published.

A processing box appearing further down the diagram indicates that the processing occurred later. This means other messages sent by other endpoints may have been processed meanwhile. The size of a processing box and the distance between them is not essential.

Failed processing

If the processing of a message failed, the processing box is displayed in red with an exclamation mark. If the message has not already been (automatically) retried, it can be retried manually via the right-click context menu.



Events are represented similarly to other messages, but with dashed lines and a different icon.

Each event published will appear once for each subscriber, as if individual messages were sent to each subscriber by the sender, regardless of whether unicast or multicast routing is used. Learn more about message routing.

Loopback messages

Loopback message

A loopback message is a message that an endpoint sends to itself and is represented by a short arrow with a special icon that does not connect to another endpoint lifeline. As with any other message, hovering over or selecting the message will highlight the processing for that message in the lifeline.

Timeout messages

Timeout message

A timeout message is a special type of loopback message where handling is deferred until later. It is represented as a loopback message with a clock icon.

The time of processing may not correspond to the time at which a timeout message was sent back for processing by the timeout message scheduler. The sequence diagram does not currently support visualization of the time at which the timeout message was sent back, and will only indicate when it was processed.

Differences from UML sequence diagrams

The language used in the sequence diagram is largely modeled after the standard defined by UML sequence diagrams. However, due to technical limitations and specifics related to messaging systems, the sequence diagram in ServiceInsight has some notable differences:

Start of sequenceSequence beginningSequence beginning
Represented by a black rectangle with a white "play" icon. This representation is used because metadata about what precedes the sequence is unavailable.Represented by an incoming message (gate) from outside the diagram.
Uni-directional solid linesSolid lineUML solid line
Used to represent any type of message other than events, including response messages.Used solely for send and request types of messages.
Uni-directional dashed linesDashed lineUML dashed line
Used solely to represent event messages.Used solely to represent create messages and response messages.
Filled arrow styleFilled arrowUML filled arrow
Used for all message types.Used solely for synchronous send messages.
Open arrow style-UML open arrow
N/AUsed for response messages and asynchronous messages.
Asynchronous messages-UML asynchronous messages
N/A - all NServiceBus messages are asynchronous so the ServiceInsight sequence diagram has no special representation for asynchronous messages and no representation for synchronous messages, even though messages may exhibit synchronous behavior by design.Represented by a sloping dashed or solid line with an open arrow.
Send to self / loopback messagesLoopback messageUML loopback message
Represented by a short uni-directional arrow that does not connect to another endpoint lifeline and a specific icon.Represented by an arrow that connects back to the sending object's lifeline. It is immediately followed by its handler, which usually overlaps the handler that sent the loopback message.
Handlers-UML handler
N/A - currently it's not possible to collect telemetry data to visualize message handlers.Represented by rectangles directly attached to arrow heads.
Message ProcessingMessage processing-
Represented by a labelled rectangle not connected with the arrows of its parent messages. This representation was chosen to reflect that the execution/processing of incoming messages may occur only after several other messages were sent, and also to reflect the default asynchronous nature of any associated response messages.N/A

Last modified