jobrunr itself doesn’t manage logging levels—it delegates to slf4j, so you configure log levels via your chosen slf4j binding (e.g., logback or log4j2), not in jobrunr code.

jobrunr itself doesn’t manage logging levels—it delegates to slf4j, so you configure log levels via your chosen slf4j binding (e.g., logback or log4j2), not in jobrunr code.

JobRunr is built on SLF4J for logging abstraction, meaning it emits log statements using the SLF4J API but relies entirely on your application’s underlying logging framework (e.g., Logback, Log4j2, or JUL) for actual log level control, formatting, and output. Since JobRunr has no internal logging configuration mechanism, setting the log level must be done externally—through your logging framework’s configuration.

✅ Recommended Approach: Configure via logback.xml (for Logback users)

If you’re using Logback (the default in Spring Boot), add or update your src/main/resources/logback.xml:

<?xml version="1.0" encoding="UTF-8"?><configuration><!-- Optional: define console appender --><appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"><encoder><pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder></appender><!-- Set JobRunr's log level to INFO (or WARN, ERROR, etc.) --><logger name="org.jobrunr" level="INFO"></logger><root level="WARN"><appender-ref ref="CONSOLE"></appender-ref></root></configuration>

This suppresses verbose DEBUG logs from JobRunr (e.g., job scheduling details, storage polling) while keeping higher-level operational messages.

? Spring Boot Users: Use application.properties

For Spring Boot projects (with spring-boot-starter-logging), simply add:

# Reduce JobRunr verbosity
logging.level.org.jobrunr=INFO

# Optional: fine-tune specific components
logging.level.org.jobrunr.storage=ERROR
logging.level.org.jobrunr.server=INFO

Spring Boot auto-configures Logback and respects these properties at startup.

⚠️ Important Notes

• No DEBUG by JobRunr itself: JobRunr doesn’t force DEBUG; it logs at appropriate levels (DEBUG, INFO, WARN, etc.)—you just happen to see DEBUG because your root logger defaults to it.
• Check your SLF4J binding: Ensure only one SLF4J implementation (e.g., logback-classic) is on the classpath. Conflicting bindings (e.g., both Logback and Log4j2) cause warnings and unpredictable behavior.
• Verify with a test log: Add a quick sanity check in your startup code:

  import org.slf4j.Logger;
  import org.slf4j.LoggerFactory;
  // ...
  Logger logger = LoggerFactory.getLogger("org.jobrunr.JobRunner");
  logger.debug("This will only appear if DEBUG is enabled for org.jobrunr");

By aligning JobRunr’s logging with your existing SLF4J setup, you gain full, centralized control—no code changes to JobRunr initialization required.