Logs

Magnolia Documentation Team

Logs

The DX Cloud Logs section in the Cockpit displays logs for pods, domains, ingresses, and more. Each section has dedicated filtering by their relevant components as well as by a date range.

There are several different types of logs which are covered on this page. See the subsections below more for more details.

Select desired cluster

Select your desired cluster from the dropdown menu at the top of the Cockpit.

Magnolia Application logs

Magnolia Application logs display log entries from Kubernetes Pods running your Magnolia application and database instances.

Key information tracked

Magnolia Application logs capture operational events including:

Application tier logs: Java application events from Magnolia Author and Public instances
Database tier logs: PostgreSQL database operations and maintenance events
Error and warning tracking: Filter by log level (FATAL, ERROR, WARN, INFO, DEBUG, TRACE)
Deployment topology: Each log identifies its source namespace, pod, container, component, and tier

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Magnolia Application:

View from the Cockpit

pod logs backend

First, select your desired cluster.
View the chart (histogram) to see log activity over time, including successful operations, warnings, and errors.
In the Filters section, you can update the following:
- Date range: Use the calendar picker for a selected range or select one of the options (e.g., Last 15 minutes).
- Namespaces: Enter namespace names to filter by specific deployment environments (e.g., staging, production).
- Pods: Enter pod names to filter by specific pod instances (e.g., staging-magnolia-helm-author-0).
- Containers: Enter container names to filter by specific containers (e.g., author-instance, author-db).
- Components: Filter by component type using checkboxes (AUTHOR or PUBLIC).
- Tiers: Filter by infrastructure tier using checkboxes (APP for application tier or DATABASE for database tier).
- Levels: Filter by log severity level using checkboxes (FATAL, ERROR, WARN, INFO, DEBUG, TRACE).
- Message filters: Enter free-text search terms to find logs containing specific keywords, error messages, or class names.

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

View from the Cockpit

magnolia backend logs table

Table 1. Example log table
Column	Description	Example
Level	The severity level of the log entry.	`WARN`
Date	The timestamp when the log entry was created, in local time format.	`Nov 10, 2025, 10:05:46 AM`
Class name	The Java class that generated the log entry (for application logs) or LOG for database logs.	`info.magnolia.cms.security.CsrfCookieTokenFilter`
Message	The log message content, which may include error details, warnings, or informational messages.	`'csrf' cookie is set with 'Secure' attribute in insecure channel. The cookie will not be sent…`
Namespace	The Kubernetes namespace where the log was generated.	`staging`
Pod	The Kubernetes pod that generated the log entry.	`staging-magnolia-helm-author-0`
Container	The container within the pod that generated the log.	`author-instance`
Component	The Magnolia component that generated the log (AUTHOR or PUBLIC).	`AUTHOR`
Tier	The infrastructure tier that generated the log (APP for application or DATABASE for database).	`APP`

Magnolia Audit logs

Magnolia Audit logs track content operations performed within your Magnolia instances. These logs record all modifications to your JCR repository content, including creating, updating, moving, copying, and deleting nodes, helping you monitor editorial activity, investigate content changes, and maintain compliance.

Key information tracked

Actions: The operation performed (create, update, delete, move, copy)
Identity: Username performing the action
Content location: Workspace, node type, source path, and destination path
Component: Whether the action occurred on Author or Public instances
Infrastructure: Namespace, pod, and container where the operation was executed
Timestamp: Precise date and time when the action occurred

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Magnolia Audit:

View from the Cockpit

magnolia audit logs

First, select your desired cluster.
View the chart (histogram) to see the content operation events over time.
In the Filters section, you can update the following:
- Date range: Use the calendar picker for a selected range or select one of the options (e.g., Last 15 minutes).
- Operations: Select one or more operation types to filter by (e.g., CREATE, UPDATE, DELETE, ACTION).
- Usernames: Enter usernames to filter by (e.g., superuser, editor@example.com).
- Workspaces: Enter workspace names to filter by (e.g., website, dam).
- Node types: Enter node types to filter by (e.g., mgnl:page, mgnl:asset).
- Source paths: Enter source paths to filter by (e.g., /travel, /dam/images/*).
- Destination paths: Enter destination paths to filter by (e.g., /archive/*).
- Components: Filter by component type (AUTHOR or PUBLIC).
- Namespaces: Enter namespaces to filter by specific deployment environments.
- Pods: Enter pod names to filter by specific pod instances.
- Containers: Enter container names to filter by specific containers.

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

View from the Cockpit

magnolia audit logs table

Table 2. Example log table
Column	Description	Example
Date	The timestamp when the content operation was performed, in ISO 8601 format (UTC).	`Nov 10, 2026, 10:42:35 AM`
Action	The type of content operation performed on the JCR node.	`CREATE`
Username	The username of the person who performed the action.	`superuser`
Workspace	The JCR workspace where the operation occurred.	`website`
Node type	The type of JCR node that was affected by the operation.	`mgnl:page`
Source path	The original path of the node before the operation (relevant for MOVE and COPY operations).	`/travel/about`
Destination path	The target path of the node after the operation (relevant for MOVE and COPY operations).	`/travel/about-us`
Component	The Magnolia component where the operation occurred.	`AUTHOR`
Namespace	The Kubernetes namespace where the operation was logged.	`staging`
Pod	The Kubernetes pod that processed the operation.	`staging-magnolia-helm-author-0`
Container	The container within the pod that handled the operation.	`dev`
Component	The Magnolia component where the operation occurred.	`author-instance`

Magnolia Publication logs

Magnolia Publication logs provide detailed visibility into content publishing operations between your author and public instances. Use these logs to monitor publishing health, troubleshoot failed transfers, analyze publishing performance, and ensure content synchronization across your public instances.

Key information tracked

Publication logs capture operational events including:

Publishing operations: Each publish or unpublish action with the content path, workspace and target subscriber
Transaction status: Whether operations succeeded, were committed to the public instance, or required rollback due to errors
Performance metrics: Publishing time and subscriber response time
User attribution: Which user initiated each publishing action
Environment context: Component, namespace, pod, and subscriber service handling the operation

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Magnolia Publication:

View from the Cockpit

publication logs

First, select your desired cluster.
View the chart (histogram) to see the content operation events over time.
In the Filters section, you can update the following:
- Date range: Date range picker to specify the period
- Namespace and pod: Namespace and pod to isolate specific deployment locations
- Component: Author or Public instance
- Content location: Workspace and path of the content published
- User: Username of the person who initiated the publish action
- Subscriber: Target public instance receiver
- Message content: Free-text search to find logs containing specific keywords or error messages
- Publishing size: Publishing size in bytes
- Publishing time: Time it took to publish the content in milliseconds
- Subscriber response time: Subscriber response time in milliseconds
- Operation type: Whether the action was an unpublish (deactivation) operation
- Transaction status: Whether the operation succeeded, was committed to the public instance, or required rollback due to errors

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

View from the Cockpit

publication logs table

Table 3. Example log table
Column	Description	Example
Date	The timestamp when the log entry was created, in local time format.	`Jan 14, 2026, 6:35:03 AM`
Name	The name of the log entry.	`integration`
Pod	The Kubernetes pod that generated the log entry.	`dev-magnolia-helm-author-0`
Component	The Magnolia component that generated the log (AUTHOR or PUBLIC).	`author-instance`
Workspace	The workspace of the published content.	`website`
Path	The path of the published content.	`travel/about-us`
Username	The username of the person who initiated the publish action.	`admin`
Subscriber	The target public instance receiver.	`dev-magnolia-helm-public-svc-0`
Message	The log message content, which may include error details, warnings, or informational messages.	`Published content to subscriber: /travel/about-us`
Publishing size	The size of the published content in bytes.	`1024`
Publishing time	The time it took to publish the content in milliseconds.	`1000`
Subscriber response time	The time it took for the subscriber to receive the content in milliseconds.	`91`
Unpublishing	Whether the operation was an unpublish (deactivation) operation.	`false`
Success	Whether the operation succeeded.	`true`
Committed	Whether the operation was committed to the public instance.	`true`
Rolledback	Whether the operation was rolled back.	`false`

Magnolia Frontend logs

Magnolia Frontend displays log information from Kubernetes Pods associated with the Magnolia frontend. You can access the pods logs by going to your Cockpit and navigating to the Logs section.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

From Logs > Magnolia Frontend:

First, select your desired cluster.
Select your desired Release from the dropdown list.
Select your desired Frontend pod from the dropdown list.
Select your desired Frontend component from the dropdown list.

This is typically the public or author instance.
Select your desired Date Range.
Input any filter terms under Term. This filters the results by the term you’ve entered.
Click Apply filters.

Filter selection persists
When you Apply filters, the selection persists meaning if you reload the page, you’ll see the same filter selection.

It also ensures you can share the selection and the recipient sees the same view as you do.
Example
https://cockpit.magnolia-platform.com/logs/events?from=2026-03-06T16:25:31.842Z&to=2026-03-06T17:25:31.842Z& (1)
1 In this case, it shows the filter for event logs for the last hour on the selected date.

Log format

Log fields

Field Description Example

date

string

The log date.

"[14/Mar/2022:16:01:50 +0000]"

log level

string

The severity of the log such as INFO or WARN.

INFO

log message

string

The log message.

info.magnolia.module.scheduler.SchedulerModule : Job configScan added [0 0 0 * * ?]. Will fire for the first time on Thu Mar 31 at 00:00:00 CEST 2026

Example

See sample file

2022-03-31 07:02:00,1982022-03-31 09:01:59,968 INFO info.magnolia.multisite.registry.MultiSiteRegistry: Following sites are registered: [sportstation, travel].
2022-03-31 10:00:00,0852022-03-31 12:00:00,002 INFO info.magnolia.module.scheduler.CommandJob : Starting job [cleanTempFiles]...
2022-03-31 10:00:00,0852022-03-31 12:00:00,003 INFO info.magnolia.module.scheduler.CommandJob : Job executed successfully [cleanTempFiles]

CDN request logs

DX Cloud stores CDN request cache logs. The default setup and deployment stores customer IPs for a configurable amount of time. If you do not want customer IPs included in the logs at all, this is also something that can be configured.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > CDN requests:

View from the Cockpit

domain logs

First, select your desired cluster.
View the chart (histogram) to see the logs such as Success (green), Client errors (yellow), and Server errors (red).
In the Filters section, you can update the following:
- Date range: Use the calendar picker for a selected range or select one of the options (e.g., Last 15 minutes).
- Method: Click one or many methods to filter by method (e.g., GET, POST, PUT, DELETE).
- Protocol: Click one or many protocols to filter by (e.g., HTTP/1.1, HTTP/2, HTTP/3).
- Hosts: Enter hosts to filter by (e.g., author., public.).
- HTTP codes: Enter HTTP codes to filter by (e.g., 401, 404, 500).
- Zones: Enter zones to filter by (e.g., FRA, NYC, SIN).^[1]
- IPs: Enter an IP address to filter by (e.g., 123.4.567.89).
- Paths: Enter a path to filter by (e.g., /.magnolia/admincentral/PUSH, /dam/*).
- Cache status: Enter a cache status to filter by (e.g., HIT, MISS, PASS, EXPIRED).
- RTT: Enter a Round-Trip Time (RTT)^[2] with an operator (e.g., >100, <50) to filter logs by network latency.
- Size: Enter a response size in KB with an operator (e.g., >1000, <500) to filter by payload size.
- Request time: Enter a request processing time in milliseconds with an operator (e.g., >5000, <100) to filter by server response time.
- User agent: Enter a user agent string to filter by (e.g., Mozilla, Chrome, bot).

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

View from the Cockpit

cdn request logs table

Table 4. Example log table
Column	Description	Example
Date	The timestamp when the request was received by the CDN, in ISO 8601 format (UTC).	`2025-10-30T10:18:05Z`
Method	The HTTP method used for the request.	`GET`
Protocol	The HTTP protocol version used for the request.	`HTTP/2`
Host	The hostname or domain that received the request.	`author.staging.wcms.customer.com`
HTTP code	The HTTP status code returned in the response.	`200`
Zone	The CDN edge location code where the request was processed.	`FRA`
IP	The client IP address that originated the request.	`128.246.11.87`
Path	The URL path that was requested.	`/.magnolia/admincentral/PUSH`
Cache status	Indicates whether the response was served from cache or passed through to the origin.	`PASS`
RTT	Round-Trip Time in milliseconds from the CDN edge to the origin server and back.	`21`
Size [B]	The response payload size in bytes.	`2049`
Request time	The total request processing time in milliseconds.	`10262`
User agent	The browser or client identification string that made the request.	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Sa…`

WAF logs

WAF logs displays log information from your Web Application Firewall rules. It only displays requests that have been blocked. You can access the WAF logs by going to your Cockpit and navigating to the Logs section.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

From Logs > WAF:

View from the Cockpit

waf logs

First, select your desired cluster.
Select your desired Domain name from the dropdown list.
Select your desired Date range.
If desired, enter a term to filter on.
Click Apply filters.

Filter selection persists
When you Apply filters, the selection persists meaning if you reload the page, you’ll see the same filter selection.

It also ensures you can share the selection and the recipient sees the same view as you do.
Example
https://cockpit.magnolia-platform.com/logs/events?from=2026-03-06T16:25:31.842Z&to=2026-03-06T17:25:31.842Z& (1)
1 In this case, it shows the filter for event logs for the last hour on the selected date.

Log format

Log fields

Field Description Example

timestamp

string

This timestamp logs the exact date and time when the event was recorded by the Web Application Firewall. It is crucial for correlating events, troubleshooting, and auditing.

"2/12/2026, 3:12:24 PM"

method

string

The method indicates the type of HTTP request made by the client. Methods include GET, POST, PUT, DELETE, etc. This information helps determine the kind of operation attempted by the client, which is useful for identifying suspicious activities.

GET

serverHostName

string

The serverHostName identifies the server or hostname that processed the request. It may represent a public domain name or an internal identifier, helping to pinpoint which server in a distributed environment handled the request.

api.example.com

path

string

The path specifies the endpoint or resource that was accessed on the server. It represents a route within your application (such as an API endpoint or webpage), and can be used to determine which parts of your system are receiving traffic.

/awesome-stuff

Ingress request logs

Ingress request logs displays log information from Kubernetes Ingresses. You can access the Ingress logs by going to your Cockpit and navigating to the Logs section.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Ingress requests:

View from the Cockpit

ingress logs

First, select your desired cluster.
View the chart (histogram) to see the logs such as Success (green), Client errors (yellow), and Server errors (red).
In the Filters section, you can update the following:
- Date range: Use the calendar picker for a selected range or select one of the options (e.g., Last 15 minutes).
- Method: Click one or many methods to filter by method (e.g., GET, POST, PUT, DELETE).
- Protocol: Click one or many protocols to filter by (e.g., HTTP/1.1, HTTP/2, HTTP/3).
- Hosts: Enter hosts to filter by (e.g., author., public.).
- HTTP codes: Enter HTTP codes to filter by (e.g., 401, 404, 500).
- IPs: Enter an IP address to filter by (e.g., 123.4.567.89).
- Paths: Enter a path to filter by (e.g., /.magnolia/admincentral/PUSH, /dam/*).
- Backend service: Enter a Kubernetes backend service name to filter by (e.g., magnolia-author-tomcat, magnolia-public-tomcat).
- Namespace: Enter a Kubernetes namespace to filter by (e.g., magnolia-prod, magnolia-staging).
- RTT: Enter a Round-Trip Time (RTT)^[3] with an operator (e.g., >100, <50) to filter logs by network latency.
- Size: Enter a response size in KB with an operator (e.g., >1000, <500) to filter by payload size.
- Request time: Enter a request processing time in milliseconds with an operator (e.g., >5000, <100) to filter by server response time.
- User agent: Enter a user agent string to filter by (e.g., Mozilla, Chrome, bot).
- Request ID: Enter a unique request identifier to filter by (e.g., a1b2c3d4e5f6).

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

View from the Cockpit

ingress request logs table

Table 5. Example log table
Column	Description	Example
Date	The timestamp when the request was received by the Ingress, in ISO 8601 format (UTC).	`2025-10-30T10:18:05Z`
Method	The HTTP method used for the request.	`GET`
Protocol	The HTTP protocol version used for the request.	`HTTP/2`
Host	The hostname or domain that received the request.	`author.staging.wcms.customer.com`
HTTP code	The HTTP status code returned in the response.	`200`
IP	The client IP address that originated the request.	`128.246.11.87`
Path	The URL path that was requested.	`/.magnolia/admincentral/PUSH`
Backend service	The Kubernetes service that handled the request.	`magnolia-author-tomcat`
Namespace	The Kubernetes namespace where the backend service resides.	`magnolia-prod`
RTT	Round-Trip Time in milliseconds from the Ingress to the backend service and back.	`21`
Size [B]	The response payload size in bytes.	`2049`
Request time	The total request processing time in milliseconds.	`10262`
User agent	The browser or client identification string that made the request.	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Sa…`
Request ID	A unique identifier assigned to the request for tracking and correlation purposes.	`a1b2c3d4e5f6g7h8i9j0`

Enterprise search logs

DX Cloud stores Enterprise search logs. You can access the logs by going to your Cockpit and navigating to the Logs section. Enterprise search logs store a range of information from application errors to slow queries.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

From Logs > Enterprise search:

First, select your desired cluster.
Select your desired Release from the dropdown list.
Select your desired Date range.
Click Apply filters.

Filter selection persists
When you Apply filters, the selection persists meaning if you reload the page, you’ll see the same filter selection.

It also ensures you can share the selection and the recipient sees the same view as you do.
Example
https://cockpit.magnolia-platform.com/logs/events?from=2026-03-06T16:25:31.842Z&to=2026-03-06T17:25:31.842Z& (1)
1 In this case, it shows the filter for event logs for the last hour on the selected date.

For more information on what you can see in these particular logs, see Solr logging.

Redirect Application logs

Redirect Application logs capture internal service events from your redirect server, providing visibility into the redirect service’s operational health and behavior. Use these logs to monitor service startup, troubleshoot configuration issues, track rule loading, and identify errors in redirect processing.

Key information tracked

Redirect Application logs capture operational events including:

Log severity: Event level (FATAL, ERROR, WARN, INFO, DEBUG, TRACE) indicating the importance of each log entry
Message content: Details about redirect service operations, configuration loading, errors, or status updates
Environment context: Namespace and pod where the redirect service is running

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Redirect Application:

First, select your desired cluster.
View the chart (histogram) to see redirect service log activity over time.
In the Filters section, you can update the following:
- Time range: Date range picker to specify the period
- Infrastructure: Namespace and pod (limited to redirect service pods)
- Log level: FATAL, ERROR, WARN, INFO, DEBUG, or TRACE severity levels
- Message content: Free-text search to find logs containing specific keywords or error messages

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

Table 6. Example log table
Column	Description	Example
Date range	The timestamp when the log entry was created, in local time format.	`Jan 14, 2026, 8:15:30 AM`
Namespace	The Kubernetes namespace where the redirect service is running.	`production`
Pod	The Kubernetes pod that generated the log entry.	`prod-redirect-server-0`
Level	The severity level of the log entry.	`INFO`
Message	The log message content, which may include status updates, configuration details, or error information.	`Redirect rules loaded successfully: 150 rules active`

Redirect Request logs

Redirect Request logs capture HTTP requests processed by your redirect service, providing visibility into how URL redirections are being handled. Use these logs to analyze redirect traffic patterns, troubleshoot redirect rule issues, monitor response times, and identify misconfigured or missing redirects.

Key information tracked

Redirect Request logs capture operational events including:

Request details: HTTP method, protocol, host, path, and client IP address for each incoming request
Response metrics: HTTP status code (301, 302, etc.), response bytes, round-trip time (RTT), and request processing time
Client information: Original client IP (via X-Forwarded-For header), user agent, and request ID for distributed tracing
Routing: Backend service that handled the request
Environment context: Namespace and pod where the redirect service processed the request

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

In addition to the guidance here, there is embedded help available directly in the Cockpit.

From Logs > Redirect Requests:

First, select your desired cluster.
View the chart (histogram) to see redirect request activity over time.
In the Filters section, you can update the following:
- Time range: Date range picker to specify the period
- Infrastructure: Namespace and pod (limited to redirect service pods)
- Request details: Method (GET, POST, etc.), protocol (HTTP/1.1, HTTP/2), host, and path
- Response: HTTP status codes (e.g., 301, 302, 404, 500)
- Client information: IP address, X-Forwarded-For (original client IP), user agent, and request ID
- Routing: Backend service that handled the request
- Performance thresholds: Request time with comparison operators

Details table

You can view log details in the Log Details table. Click Download logs (CSV) to download the logs locally. To view a specific log, click the log in the table. This triggers a detailed view of the log.

Table 7. Example log table
Column	Description	Example
Date	The timestamp when the redirect request was received, in local time format.	`Jan 14, 2026, 10:23:45 AM`
Namespace	The Kubernetes namespace where the redirect service processed the request.	`production`
X-Forwarded-For	The original client IP address when requests pass through proxies or load balancers.	`10.0.0.50`
Backend	The backend service that handled the redirect request.	`redirect-service`
Request ID	The unique identifier assigned to the request for distributed tracing and correlation.	`abc123-def456-ghi789`
Host	The hostname or domain that received the request.	`www.example.com`
HTTP code	The HTTP status code returned (typically 301, 302, 307, or 308 for redirects).	`301`
Method	The HTTP method used for the request.	`GET`
Protocol	The HTTP protocol version used for the request.	`HTTP/2`
IP	The client IP address that originated the request.	`192.168.1.100`
Path	The URL path that was requested before redirection.	`/old-page`
User agent	The browser or client identification string that made the request.	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0`
Size	The response payload size in bytes.	`256`
Request time	The total request processing time in milliseconds.	`25`

Event logs

The Events section in the Cockpit displays information about the events within the cluster. These events are objects that show you exactly what is occurring inside your cluster, such as scheduler decisions or why some pods are being evicted from a node.

Generally, we keep logs for 30 days. However, for your deployment, you may configure a different duration.

You can select up to the last 7 days for this filter.

Instructions

From Logs > Events:

View from the Cockpit

cluster events

First, select your desired cluster.
Select the Start and End date range.
If desired, enter a term to filter on.
Click Apply filters.

Filter selection persists
When you Apply filters, the selection persists meaning if you reload the page, you’ll see the same filter selection.

It also ensures you can share the selection and the recipient sees the same view as you do.
Example
https://cockpit.magnolia-platform.com/logs/events?from=2026-03-06T16:25:31.842Z&to=2026-03-06T17:25:31.842Z& (1)
1 In this case, it shows the filter for event logs for the last hour on the selected date.

Log format

Field Description Example

date

string

2/10/2026 4:45:56 AM

action

string

StartKubeProxy

message

string

Reading config file /data/config.yaml

1. Zones refer to CDN edge location codes representing geographic regions.

2. A network performance metric that measures the time in milliseconds for a request to travel from the CDN edge to the origin server and back again.

3. A network performance metric that measures the time in milliseconds for a request to travel from the Ingress to the backend service and back again.

Logs

Select desired cluster

Magnolia Application logs

Key information tracked

Instructions

Details table

Magnolia Audit logs

Key information tracked

Instructions

Details table

Magnolia Publication logs

Key information tracked

Instructions

Details table

Magnolia Frontend logs

Instructions

Log format

Example

CDN request logs

Instructions

Details table

WAF logs

Instructions

Log format

Ingress request logs

Instructions

Details table

Enterprise search logs

Instructions

Redirect Application logs

Key information tracked

Instructions

Details table

Redirect Request logs

Key information tracked

Instructions

Details table

Event logs

Instructions

Log format

Location

Main doc sections