DEADLINE

Specifies the maximum interval within which a new sample for a given data instance must be produced by the Publisher and received by the Subscriber.

What it controls

The maximum expected period between consecutive samples per instance. Missed deadlines trigger requested_deadline_missed or offered_deadline_missed callbacks.

Key settings

Field	Default	Mutability
period	infinity	Can be changed at runtime

Compatibility role

Matching and timing — Writer offered deadline period must not exceed Reader requested period (RxO). Monitors sample freshness during data exchange and interacts with lifespan and liveliness lease durations.

When this conflicts

Deadline takes part in the following QoS Guard rules. Each links to a full explanation with an example and a fix.

Lifespan shorter than the deadline period with LifespanBreaks a guarantee Exclusive ownership with no deadline to trigger failover with OwnershipBreaks a guarantee Deadline monitoring interrupted when partitions change with PartitionBreaks a guarantee Publisher's deadline is slower than the subscriber demands with itselfWon't connect Best-effort loss triggers false deadline-missed events with ReliabilityBreaks a guarantee Liveliness lease shorter than the deadline period with LivelinessBreaks a guarantee Deadline too tight for the link forces needless ownership handover with OwnershipWastes resources Durable replay resets the deadline timer for a late joiner with DurabilityWastes resources

Related policies

• LIFESPAN
• OWNERSHIP
• PARTITION
• RELIABILITY
• LIVELINESS
• DURABILITY

Example

The DEADLN QoS can be used for real-time monitoring of robot status. Each robot may publish its position and battery level through ROS 2 topics every second. The Publisher and the central monitoring system's Subscriber are both configured with a period of 1 second. If a new sample fails to arrive within this interval, the monitoring system receives a deadline-miss notification, enabling immediate detection of communication failures or faults in that data stream. The application can then respond by issuing alerts or stopping the robot, thereby enhancing overall system safety and reliability.