skip to content

auditevents Endpoint & AuditEventRepository

4 roadmaps5 questions

The audit events endpoint exposes an AuditEventRepository that records who did what, fed by Spring Security's authentication events among others. Interviewers ask where login failures get recorded, and this is one honest answer.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What is the Spring Boot Actuator /actuator/auditevents endpoint and what does it show?

level: juniorimportance: should knowfreq 25%

answer

  1. principal / type / timestamp / data map
  2. auth success + failure recorded automatically
  3. not exposed by default — include it
  4. needs an AuditEventRepository bean or 404
  5. filter by principal, type, after

basics

~20 s

It is an Actuator endpoint that exposes a list of recorded audit events — security-relevant actions like login success or failure — each with a principal (who), a type (what), a timestamp, and a data map of details.

solid answer

~40 s

/actuator/auditevents is a built-in Actuator endpoint that returns audit events captured by the application. Each AuditEvent carries a timestamp, a principal (the user/identity involved), a type (a short code like AUTHENTICATION_SUCCESS or AUTHENTICATION_FAILURE), and a data map of extra details. Out of the box Spring Security auth events are recorded, so you can see who logged in or failed to log in. You can filter with query params: principal, after (an ISO timestamp), and type. Two things are required for it to work: the endpoint must be exposed over the web (management.endpoints.web.exposure.include=auditevents), and an AuditEventRepository bean must exist to store the events. It is enabled by default but not web-exposed by default, and it should be locked down because it reveals security activity.

code

java · 15 lines
java
// application.properties
// management.endpoints.web.exposure.include=health,auditevents

// GET /actuator/auditevents?type=AUTHENTICATION_FAILURE
// {
//   "events": [
//     {
//       "timestamp": "2026-07-22T09:15:04.120Z",
//       "principal": "alice",
//       "type": "AUTHENTICATION_FAILURE",
//       "data": { "type": "org.springframework.security.authentication.BadCredentialsException",
//                  "message": "Bad credentials" }
//     }
//   ]
// }

go deeper

for a junior

Know it lists audit events with principal/type/timestamp/data and that Spring Security logins appear there.

for a middle

Know the exposure requirement and the query filters; know events must be stored in a repository.

for a senior

Explain the AuditEventRepository conditional wiring and the 404 gotcha; treat exposure as a security concern.

for a principal

Frame it as a lightweight, per-instance, non-persistent trail — not a compliance-grade audit system.

**What it is.** `/actuator/auditevents` is one of Spring Boot Actuator's built-in management endpoints. Actuator adds production-monitoring endpoints (health, metrics, info, etc.) under the `/actuator` base path when you add the `spring-boot-starter-actuator` dependency. The `auditevents` endpoint surfaces an *audit trail*: a record of security-significant events the application has captured. **The data model — `AuditEvent`.** Each entry is an `org.springframework.boot.actuate.audit.AuditEvent` with four parts: - `timestamp` (`java.time.Instant`) — when it happened. - `principal` (`String`) — the identity involved, e.g. the username `alice`, or `anonymousUser`. - `type` (`String`) — a short classification code, e.g. `AUTHENTICATION_SUCCESS`, `AUTHENTICATION_FAILURE`, `AUTHORIZATION_FAILURE`. This is just a string; you choose your own for custom events. - `data` (`Map<String, Object>`) — arbitrary extra context, e.g. the remote address, the failure reason, request details. **Where events come from.** By default Spring Boot wires Spring Security's authentication events into the audit system, so login successes and failures show up automatically. You can also publish your own (see the sibling questions). **Two prerequisites (common gotchas).** 1. **Exposure.** Only `health` is web-exposed by default. To reach `auditevents` over HTTP you must add it: `management.endpoints.web.exposure.include=health,auditevents` (or `*`). The endpoint is *enabled* by default but not *exposed*. 2. **An `AuditEventRepository` bean.** The whole audit infrastructure (including the endpoint bean) is conditional on an `AuditEventRepository` bean being present. If none exists, the endpoint returns 404 even when 'exposed'. Spring provides `InMemoryAuditEventRepository`, but you typically must declare it as a bean yourself. **Querying.** `GET /actuator/auditevents` returns all buffered events. You can filter: `?principal=alice`, `?type=AUTHENTICATION_FAILURE`, `?after=2026-01-01T00:00:00Z` (an offset/ISO date-time). Filters combine. **Security caveat.** This endpoint reveals who authenticated and when — sensitive information. Never expose it unauthenticated in production; put it behind admin authorization and ideally a separate management port. **When to use.** Quick built-in audit trail for auth activity in a single instance, dev/ops visibility, or a lightweight starting point before you build a real persisted audit log.

  • Why might /actuator/auditevents return 404 even though you added it to exposure.include?
    Because there is no AuditEventRepository bean. The audit auto-configuration and the endpoint are @ConditionalOnBean(AuditEventRepository.class); with no repository present, the endpoint isn't registered. Declaring an InMemoryAuditEventRepository bean fixes it.
  • What query parameters does the endpoint support?
    principal (identity), type (event type code), and after (an ISO/offset date-time lower bound). They combine to filter the returned events.

saying these in an interview costs you the question

  • Thinking auditevents is exposed over HTTP by default (only health is).
  • Assuming it works without any AuditEventRepository bean.
  • Confusing it with /actuator/httptrace or /httpexchanges (request tracing, not audit events).
  • Believing it persists across restarts by default.

context

resolving links…

open as a page

How do you publish a custom audit event, and what is the structure of an AuditEvent?

level: middleimportance: should knowfreq 30%

basics

~10 s

Build an AuditEvent(principal, type, data-map), wrap it in an AuditApplicationEvent, and publish it with ApplicationEventPublisher.publishEvent(...). Spring's AuditListener stores it in the AuditEventRepository so it appears at /actuator/auditevents.

open as a page

What is InMemoryAuditEventRepository, what are its limitations, and how do you provide a custom AuditEventRepository?

level: seniorimportance: should knowfreq 22%

basics

~20 s

InMemoryAuditEventRepository is Spring's default store: a fixed-size (default 4000) in-memory circular buffer of AuditEvents. It's per-instance and lost on restart. For durability you implement the AuditEventRepository interface (add + find) backed by a database or log/SIEM and declare it as a bean.

open as a page

How does Spring Security integrate with Actuator auditing to record authentication success and failure events?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Spring Security fires application events on auth success and failure. Spring Boot's AuthenticationAuditListener listens for them and converts each into an AuditEvent (type AUTHENTICATION_SUCCESS or AUTHENTICATION_FAILURE) stored in the AuditEventRepository, so they appear at /actuator/auditevents.

open as a page

How would you use the auditevents endpoint safely and effectively for a production, multi-instance service?

level: principalimportance: should knowfreq 16%

basics

~20 s

Treat the endpoint as sensitive: expose it only behind admin auth (ideally a separate management port), don't rely on the volatile per-node in-memory store for compliance, forward audit events to a durable central store/SIEM, scrub secrets from the data map, and set retention policies.

open as a page