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.

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.


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.

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.

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.

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