Introduction

Scheduled WebSocket push in Spring Boot is a common pattern when clients need periodic updates without polling over HTTP. The usual design is simple: enable scheduling, publish messages on a schedule, and deliver them to subscribed clients through Spring's WebSocket messaging support. The real work is choosing the right destination structure and making sure scheduled jobs do not overwhelm connected sessions.

Configure WebSocket Messaging

The most common Spring Boot setup uses STOMP over WebSocket with a simple broker.

1import org.springframework.context.annotation.Configuration;
2import org.springframework.messaging.simp.config.MessageBrokerRegistry;
3import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
4import org.springframework.web.socket.config.annotation.StompEndpointRegistry;
5import org.springframework.web.socket.config.annotation.WebSocketMessageBrokerConfigurer;
6
7@Configuration
8@EnableWebSocketMessageBroker
9public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
10    @Override
11    public void configureMessageBroker(MessageBrokerRegistry registry) {
12        registry.enableSimpleBroker("/topic");
13        registry.setApplicationDestinationPrefixes("/app");
14    }
15
16    @Override
17    public void registerStompEndpoints(StompEndpointRegistry registry) {
18        registry.addEndpoint("/ws").setAllowedOriginPatterns("*");
19    }
20}

With this setup, clients can subscribe to destinations such as /topic/status.

Enable Scheduling and Push Periodic Messages

Next, use @Scheduled together with SimpMessagingTemplate to publish updates.

1import java.time.Instant;
2import java.util.Map;
3import org.springframework.messaging.simp.SimpMessagingTemplate;
4import org.springframework.scheduling.annotation.Scheduled;
5import org.springframework.stereotype.Component;
6
7@Component
8public class StatusPublisher {
9    private final SimpMessagingTemplate messagingTemplate;
10
11    public StatusPublisher(SimpMessagingTemplate messagingTemplate) {
12        this.messagingTemplate = messagingTemplate;
13    }
14
15    @Scheduled(fixedRate = 5000)
16    public void publishStatus() {
17        messagingTemplate.convertAndSend(
18            "/topic/status",
19            Map.of("time", Instant.now().toString(), "state", "ok")
20        );
21    }
22}

And enable scheduling in the application:

1import org.springframework.boot.autoconfigure.SpringBootApplication;
2import org.springframework.scheduling.annotation.EnableScheduling;
3
4@SpringBootApplication
5@EnableScheduling
6public class DemoApplication {
7}

That is enough for periodic server push.

Keep the Payload and Destination Design Clean

Scheduled pushes often start small and then grow. A useful pattern is:

1. use one topic per data family
2. keep payloads compact and versionable
3. avoid sending the same heavy message to everyone if only a few users need it

If updates are user-specific, consider destinations scoped by user or account rather than broadcasting globally.

Consider the Scheduler's Runtime Behavior

A scheduled push method runs whether or not clients are actively listening, unless you add your own guardrails. For lightweight status messages that may be fine. For heavy queries or large payload generation, it is worth checking whether the schedule should be conditional or whether the data should be cached and reused across subscribers.

That distinction becomes important as soon as the push job depends on database reads or external APIs rather than constant in-memory data.

Know When Scheduling Is the Wrong Trigger

A scheduled push is appropriate for periodic status snapshots, clock-like updates, or summarized metrics. It is not always the best fit for event-driven data. If the server already knows exactly when data changes, pushing immediately from the domain event is often better than waiting for the next scheduled tick.

The right question is not "can I schedule it". The right question is "should this update be periodic or event-driven".

Client Subscription Example

A typical JavaScript STOMP client subscribes once and then just listens:

1stompClient.subscribe("/topic/status", message => {
2  const payload = JSON.parse(message.body);
3  console.log(payload);
4});

From the client side, scheduled push looks the same as any other server-sent WebSocket message.

Common Pitfalls

• Using scheduled pushes for data that should really be emitted on demand or on domain events.
• Broadcasting large payloads to all clients when only some clients need them.
• Forgetting to enable scheduling, which makes the publisher appear broken.
• Mixing REST and WebSocket destination design without a clear message contract.
• Sending updates too frequently and creating unnecessary load on both server and browser clients.

Summary

• Scheduled WebSocket push in Spring Boot usually combines @EnableScheduling with SimpMessagingTemplate.
• STOMP destinations such as /topic/... make periodic broadcast easy.
• Choose topic structure and payload size carefully before the feature grows.
• Use scheduled push for periodic data, not as a default replacement for event-driven updates.
• The server side is simple once scheduling, broker config, and destination design are aligned.