3. Spring Boot: Starter Dependencies and Actuator

Spring Boot : Starter Dependencies and Actuator — From Dependency Complexity to Production Observability

Experience Level: Intermediate to Experienced Java Developers
Series: Spring Boot Tutorial
Topics: Spring Boot Starter Dependencies · Spring Boot Actuator · Production Monitoring · SRE · Observability

Introduction

A Spring application has two very different phases of its life.

During development, the team is primarily concerned with:

• Building business functionality
• Writing APIs
• Implementing business rules
• Connecting databases
• Testing features
• Fixing functional defects

But once the application is ready for production, another set of questions becomes important:

Is the application running?
Is the database connection healthy?
Is the JVM under memory pressure?
Are requests becoming slow?
Are errors increasing?
How do we know that something is wrong before users report it?

Spring Boot addresses both sides of this problem with features such as Starter Dependencies and Spring Boot Actuator.

Starter dependencies simplify the development setup, while Actuator helps with the operational side of running the application.

1. The First Problem: Building the Dependency Graph

Let’s say you’re developing a Spring application that needs JDBC.

At first, the requirement sounds straightforward:

Application
     ↓
JDBC
     ↓
Database

But the actual dependency graph can be much larger.

Your application may require:

Application
    ↓
Spring JDBC
    ↓
Spring Core
    ↓
Connection Pool
    ↓
Database Driver
    ↓
Database

And if transactions are involved:

Application
    ↓
JDBC
    ├── DataSource
    ├── Transaction Management
    └── Database Driver

The developer therefore isn’t simply choosing one library.

They need a compatible collection of libraries.

2. What Happens Without Starter Dependencies?

Suppose you’re creating a Spring application manually.

You need to determine:

• Which Spring module is required?
• Which version should be used?
• Which supporting libraries are needed?
• Which third-party dependencies are required?
• Which versions are compatible?
• Which transitive dependencies will be brought in?
• Are there conflicting versions?

This becomes particularly difficult when an application uses several Spring capabilities.

For example:

Web
 +
Database
 +
JPA
 +
Transactions
 +
Validation
 +
Security

Each capability can introduce additional dependencies.

The dependency graph can therefore become:

Application
   │
   ├── Spring Module A
   │       ├── Library X
   │       └── Library Y
   │
   ├── Spring Module B
   │       ├── Library Y
   │       └── Library Z
   │
   └── Spring Module C
           └── Library X

Now the developer has to ensure that all of these pieces work together.

3. Why Version Management Becomes Difficult

Consider a simplified example.

Suppose:

Spring Module A → Version X
Spring Module B → Version Y
Third-party Library → Version Z

The versions cannot always be selected independently.

A newer version of one library might require a particular version of another library.

This can lead to:

• Dependency conflicts
• Runtime errors
• Incompatible APIs
• Unexpected behavior
• Difficult debugging

And the worst part is that these problems may not appear immediately.

The application might compile successfully and fail only when a particular code path executes.

4. The Developer’s Time Is Not Free

This is an important engineering perspective.

Imagine a team spending several hours or days determining:

Which dependencies?
Which versions?
Which transitive dependencies?
Which combinations are compatible?

That time doesn’t create any business functionality.

The customer isn’t paying for:

“We spent three days figuring out which supporting library version is compatible.”

The customer is paying for:

“We delivered the required application functionality.”

This is where Spring Boot Starter Dependencies become valuable.

5. What Is a Spring Boot Starter?

A Spring Boot Starter is essentially a convenient dependency descriptor that groups the dependencies commonly needed for a particular application capability.

Instead of manually assembling a collection of related dependencies, you can select an appropriate starter.

For example:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>

The exact dependencies brought into the application are managed through Spring Boot’s dependency-management mechanism.

The developer’s decision becomes:

“My application needs JDBC support.”

rather than:

“Let me manually discover every Spring and supporting library required for JDBC.”

6. What a Starter Actually Does

A starter primarily addresses dependency selection and dependency management.

Think of it like a predefined package of related dependencies:

                JDBC Requirement
                       ↓
          spring-boot-starter-jdbc
                       ↓
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
 Spring JDBC      Supporting       Required
 Components       Libraries        Dependencies

This dramatically reduces the amount of dependency discovery a developer has to perform manually.

Important distinction

A starter dependency and auto-configuration are not the same thing.

A useful mental model is:

Starter
   ↓
Brings required dependencies
   ↓
Dependencies are available

Spring Boot Auto-Configuration
   ↓
Detects those capabilities
   ↓
Configures suitable infrastructure

So:

Starter = dependency setup

while:

Auto-Configuration = infrastructure configuration

They work together, but they solve different problems.

7. What If We Don’t Use Starters?

You can still build a Spring application without using Spring Boot starters.

There is nothing technically impossible about it.

You can manually declare the required dependencies.

However, you take on more responsibility.

Without starters

Developer
   ↓
Identify dependencies
   ↓
Select versions
   ↓
Check compatibility
   ↓
Resolve transitive dependencies
   ↓
Test combinations
   ↓
Maintain them over time

With starters

Developer
   ↓
Choose application capability
   ↓
Add appropriate starter
   ↓
Spring Boot dependency management
   ↓
Compatible dependency set

The second approach is usually much more productive for standard Spring Boot applications.

8. Advantages of Starter Dependencies

Reduced dependency-management effort

You don’t have to manually identify every common supporting dependency.

Better consistency

Spring Boot’s dependency management provides a coordinated set of versions.

Faster project setup

A developer can start implementing functionality sooner.

Easier maintenance

Upgrading Spring Boot can update the managed dependency set together rather than requiring developers to individually research many versions.

Lower risk of dependency mistakes

There are fewer opportunities to accidentally combine incompatible versions.

9. Are Starters Mandatory?

No.

They are a convenience and an important part of the Spring Boot development model, but they aren’t a fundamental requirement for every possible Spring application.

You can explicitly declare dependencies when you need finer control.

This is particularly relevant when:

• You need a specialized library
• You don’t want a particular transitive dependency
• You have unusual architectural requirements
• You are deliberately controlling the dependency graph

Experienced developers should therefore understand both approaches.

10. Now Consider the Other Side: Production

Imagine a team has spent 8–9 months building an application.

During those months, developers and QA engineers have concentrated primarily on:

Business Requirements
       ↓
Development
       ↓
Testing
       ↓
Bug Fixing
       ↓
Performance Testing
       ↓
Release Preparation

Now someone asks:

“How will we monitor this application after deployment?”

That’s a completely different problem.

The team now needs answers to questions such as:

• Is the application alive?
• Is it ready to process requests?
• Is the database reachable?
• How many requests are coming in?
• How long are requests taking?
• How much memory is being used?
• How many errors are occurring?
• What is happening inside the JVM?

If these capabilities have to be designed and implemented from scratch at the end, the team may need significant additional development and testing effort.

11. Why Production Monitoring Is Not Optional

An application can pass functional testing and still fail in production.

For example:

Application starts successfully
        ↓
Users begin accessing it
        ↓
Traffic increases
        ↓
Memory usage increases
        ↓
Response time increases
        ↓
Errors increase
        ↓
Application becomes unhealthy

Functional testing might have confirmed:

“The order API works.”

Production monitoring needs to answer:

“Is the order API working reliably right now?”

Those are different questions.

12. What Is Spring Boot Actuator?

Spring Boot Actuator provides production-oriented features for monitoring and managing Spring Boot applications.

It exposes information about the running application through management endpoints.

For example, commonly used endpoints include:

/actuator/health
/actuator/info
/actuator/metrics

The exact endpoints exposed depend on configuration and the Spring Boot version.

The important concept is:

Application
     ↓
Spring Boot Actuator
     ↓
Management Endpoints
     ↓
Monitoring / Operations Systems

13. Health Checks

One of the most important operational capabilities is health information.

For example:

Application
     ↓
Health Check
     ↓
Database
     ↓
Other Dependencies

An external system can use health information to determine whether an application instance is healthy.

This becomes particularly valuable when applications are deployed in environments where instances are created, removed, restarted, or replaced automatically.

For example:

Load Balancer
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
App1 App2 App3

If App2 becomes unhealthy, the surrounding infrastructure can potentially stop sending traffic to it, depending on how the deployment platform is configured.

14. Metrics: Going Beyond “Is It Alive?”

Health tells us something important:

“Is the application healthy?”

But production teams often need much more information.

For example:

Requests per second
Average response time
Error count
JVM memory
CPU usage
Garbage collection
Thread activity
Database connection information

This is where metrics become valuable.

Instead of looking at the application manually, we can collect measurements over time.

Time
 ↓
Metrics
 ↓
Trend
 ↓
Detection
 ↓
Action

15. JVM and Runtime Visibility

A Java application runs inside a JVM.

Therefore, application-level monitoring alone isn’t enough.

The operations team may also care about:

Heap Memory
Non-Heap Memory
Threads
Garbage Collection
CPU
Uptime
Class Loading

These measurements can help engineers distinguish between different types of problems.

For example:

High response time
      ↓
Check CPU
      ↓
Check memory
      ↓
Check GC
      ↓
Check threads
      ↓
Check database

This makes troubleshooting much more systematic.

16. Where SRE Fits In

This brings us to SRE — Site Reliability Engineering.

SRE focuses on operating software systems reliably at scale.

A simplified model is:

Development
     ↓
Application
     ↓
Production
     ↓
Monitoring
     ↓
Detection
     ↓
Response
     ↓
Reliability

Developers build the application.

SRE / DevOps / Operations teams help ensure that the application remains:

• Available
• Observable
• Reliable
• Performant
• Recoverable

The exact responsibilities vary between organizations.

17. Actuator Does Not Replace Monitoring Platforms

This is an important distinction.

Spring Boot Actuator provides application management and observability endpoints.

It is not itself a complete enterprise monitoring platform.

Think of the architecture like this:

Spring Boot Application
          ↓
       Actuator
          ↓
   Metrics / Health / Info
          ↓
 Observability Platform
          ↓
 Dashboards / Alerts / Analysis

Tools such as:

• Datadog
• Prometheus
• Grafana
• New Relic
• Elastic Stack
• Cloud monitoring platforms

can consume or work with telemetry from applications.

The exact integration depends on the platform and architecture.

18. Example: Datadog in Production

Imagine your application is running on multiple servers or containers.

          Users
            ↓
       Load Balancer
            ↓
     ┌──────┼──────┐
     ↓      ↓      ↓
   App-1  App-2  App-3
     │      │      │
     └──────┼──────┘
            ↓
       Monitoring
            ↓
         Datadog

The monitoring platform can aggregate application and infrastructure telemetry.

The operations team can then create dashboards such as:

Request Rate
    ↓
Response Time
    ↓
Error Rate
    ↓
CPU
    ↓
Memory
    ↓
Application Health

Instead of waiting for a customer to say:

“The application is slow.”

the team can potentially detect abnormal behavior from telemetry.

19. What Does an SRE Actually Do With This Information?

Suppose monitoring shows:

Normal response time: 200 ms

Current response time:
1.2 seconds

At the same time:

CPU → Normal
Memory → Normal
GC → Normal
Database latency → Very High

The SRE doesn’t immediately blame the application server.

The telemetry provides a clue:

Application slowdown
       ↓
Database latency increased
       ↓
Investigate database

Another scenario:

Response time ↑
CPU ↑
Memory → Normal

This may lead to a different investigation.

The value of monitoring is therefore not simply displaying numbers.

It provides evidence for troubleshooting.

20. Actuator and Observability

A useful modern concept here is observability.

Observability generally involves understanding the internal state of a system from the telemetry it produces.

Three commonly discussed signals are:

Metrics
Logs
Traces

Metrics

Numerical measurements over time.

Example:

HTTP request rate = 500 requests/sec

Logs

Detailed event information.

Example:

Payment service failed to connect to database

Traces

Show how a request travels through distributed services.

API Gateway
    ↓
Order Service
    ↓
Payment Service
    ↓
Inventory Service
    ↓
Database

Actuator is an important part of the Spring Boot operational ecosystem, while broader observability usually involves additional tools and instrumentation.

21. Without Actuator vs With Actuator

Without Actuator

The team may need to build or assemble many operational capabilities themselves:

Custom health endpoints
Custom application metrics
Custom JVM information
Custom monitoring integration
Custom operational checks

This creates additional engineering work.

The team must then:

Develop
   ↓
Test
   ↓
Deploy
   ↓
Maintain

all of those additional capabilities.

With Actuator

Spring Boot provides ready-made management capabilities that can be enabled and configured.

Spring Boot Application
        ↓
      Actuator
        ↓
 ┌──────┼─────────┐
 ↓      ↓         ↓
Health Metrics   Info
        ↓
Monitoring Ecosystem

This doesn’t eliminate all observability work, but it gives the team a strong foundation.

22. The Cost Perspective

This is where the topic becomes especially relevant to real-world engineering.

Suppose a team spends months developing an application.

Then, just before production, the organization realizes it needs:

Health Monitoring
Metrics
JVM Monitoring
Operational Endpoints
Monitoring Integration
Alerts
Dashboards

If everything is built manually, the work may require:

Development
+
QA
+
Deployment
+
Operations

That means additional:

• Engineering hours
• Testing effort
• Release coordination
• Maintenance
• Operational complexity

The exact cost and duration depend heavily on the application and organization, so there is no universal “two months” or “three months” figure.

The important point is:

Operational capabilities should be considered part of the application’s lifecycle, not an afterthought immediately before production.

Actuator helps reduce the amount of custom work required for common Spring Boot management capabilities.

23. Why This Is Valuable to a Developer

A developer shouldn’t think:

“Actuator is only for the operations team.”

That’s too narrow.

During development, Actuator can help developers understand their application’s runtime behavior.

For example:

Application
    ↓
Actuator
    ↓
Health / Metrics
    ↓
Developer
    ↓
Troubleshooting

A developer can use this information while investigating:

• Performance problems
• Configuration issues
• Application health
• Runtime behavior
• Resource consumption

So Actuator is useful throughout the application lifecycle.

24. Why QA Teams Benefit Too

QA teams don’t only test whether:

“The button works.”

They may also need to validate system behavior under realistic conditions.

For example:

Load Test
   ↓
Requests increase
   ↓
Response time measured
   ↓
Error rate observed
   ↓
Resource utilization observed

Metrics and health information can help correlate functional testing with runtime behavior.

This gives QA and performance engineers better visibility into the system.

25. Why Operations Teams Benefit

Once deployed, operations teams need to answer:

Is the service available?

Is it healthy?

Are requests failing?

Is latency increasing?

Is resource utilization abnormal?

Which instance is affected?

Did something change after deployment?

Actuator endpoints can provide application-level information that becomes useful to these teams and to monitoring systems.

26. The Complete Production Picture

A modern production environment can look conceptually like this:

                 USERS
                   │
                   ▼
             Load Balancer
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
        App-1    App-2    App-3
          │        │        │
          └────────┼────────┘
                   │
                   ▼
             Spring Boot
                   │
                   ▼
               Actuator
                   │
          ┌────────┼─────────┐
          ▼        ▼         ▼
       Health   Metrics     Info
          │        │
          └────────┼─────────┘
                   ▼
          Observability Stack
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
     Metrics     Alerts    Dashboards
        │          │          │
        └──────────┼──────────┘
                   ▼
              SRE / Ops
                   │
                   ▼
              Investigation

This is where a simple Spring Boot feature becomes part of a much larger production ecosystem.

27. Starters and Actuator Solve Different Problems

Don’t combine these two concepts into one.

The relationship can be understood as:

STARTER
   ↓
Dependencies
   ↓
AUTO-CONFIGURATION
   ↓
Application Infrastructure
   ↓
APPLICATION
   ↓
ACTUATOR
   ↓
Telemetry / Management Information
   ↓
MONITORING PLATFORM
   ↓
SRE / OPERATIONS

28. What If We Use Neither?

Technically, you can build applications without Spring Boot starters and without Actuator.

But you take on more responsibility.

Without Starter Dependencies

Pros

• Maximum control over individual dependencies
• Useful for specialized scenarios

Cons

• More dependency-management work
• More version decisions
• Greater possibility of conflicts
• More maintenance effort
• Slower initial setup

Without Actuator

Pros

• Fewer dependencies/features
• Potentially smaller management surface
• You can design your own operational endpoints

Cons

• More custom monitoring work
• More development and testing
• More operational maintenance
• Harder to standardize common management capabilities

29. With Both

Using appropriate starters and Actuator gives a more streamlined development-to-production path:

Developer
   ↓
Choose required capability
   ↓
Starter Dependencies
   ↓
Dependency Management
   ↓
Auto-Configuration
   ↓
Build Business Features
   ↓
Actuator
   ↓
Health + Metrics + Management
   ↓
Monitoring Platform
   ↓
SRE / Operations
   ↓
Reliable Production System

This doesn’t mean every application needs every Spring Boot feature.

Good engineering still requires choosing only what the application actually needs.

30. A Practical Example

Imagine you’re building an Order Management Service.

Development requirement

The application needs:

REST API
+
Database
+
Transactions

Appropriate Spring Boot starters can simplify dependency setup.

Then the application is developed and tested.

Before production, Actuator can provide management capabilities such as:

Health
Metrics
Application Information

A monitoring platform can then consume appropriate telemetry.

In production:

Customer
   ↓
Order API
   ↓
Spring Boot Application
   ↓
Database

Meanwhile:

Application
   ↓
Actuator / Metrics
   ↓
Monitoring Platform
   ↓
SRE Dashboard
   ↓
Alert

The business request and the operational monitoring path run alongside each other.

31. The Engineering Lesson

There is a larger lesson behind these two Spring Boot features.

Good frameworks don’t only help developers write business logic.

They also reduce repetitive engineering work around the application lifecycle.

Starter Dependencies reduce:

Dependency discovery
Version selection
Compatibility management

Actuator reduces:

Custom operational plumbing
Basic health implementation
Basic application metrics exposure

Together:

Less Repetitive Work
        ↓
Faster Development
        ↓
Lower Engineering Overhead
        ↓
Better Production Readiness

32. What Experienced Developers Should Remember

Don’t memorize:

“spring-boot-starter-jdbc is a dependency.”

Understand why it exists.

The deeper question is:

“What problem does this abstraction remove?”

Likewise, don’t memorize:

“/actuator/health is an endpoint.”

Understand:

“How does health information become useful when my application is running as one instance among hundreds of production instances?”

That’s the level of understanding expected when moving from a framework user toward an experienced backend engineer.

Key Takeaways

Starter Dependencies

• Simplify dependency selection.
• Group commonly required dependencies for a particular capability.
• Reduce manual dependency discovery.
• Work with Spring Boot’s dependency-management approach.
• Help reduce version compatibility problems.
• Do not confuse starters with auto-configuration.

Spring Boot Actuator

• Provides production-oriented management and monitoring capabilities.
• Exposes endpoints such as health, metrics, and application information.
• Helps developers, QA, DevOps, SRE, and operations teams.
• Can provide application-level telemetry for monitoring systems.
• Does not replace a complete monitoring/observability platform.
• Helps reduce the need to build common operational capabilities from scratch.

Final Mental Model

Remember these three layers:

                    DEVELOPMENT
                         │
                         ▼
              ┌────────────────────┐
              │ Starter Dependencies│
              └─────────┬──────────┘
                        │
                        ▼
               Dependency Setup
                        │
                        ▼
              ┌────────────────────┐
              │  Auto-Configuration │
              └─────────┬──────────┘
                        │
                        ▼
                Spring Infrastructure
                        │
                        ▼
                  Business Logic
                        │
                        ▼
                    PRODUCTION
                        │
                        ▼
              ┌────────────────────┐
              │ Spring Boot Actuator│
              └─────────┬──────────┘
                        │
                        ▼
              Health + Metrics + Info
                        │
                        ▼
              Monitoring Platform
                        │
                        ▼
                 SRE / Operations
                        │
                        ▼
              Reliable Production

The core idea is:

Starter Dependencies help you assemble the application. Actuator helps you understand and operate the application once it is running.

And that is the real value of these features—not simply fewer lines of code, but less repetitive engineering work across the application lifecycle.