Pod Logs

Clicking the Logs tab allows you to see all the logs generated by the pods created during your workflow run.

Downloading Pod Logs

Click the Download button to download the logs for the run. This will download a text file containing logs that conform with both your filter and search criteria.

Filtering Logs

By default, you are shown only the main container logs for each pod running in your workflow. You can click the Advanced Filters button to include other container logs. You can also choose individual Pods or Nodes to view.

Searching Logs

Click the Search icon button to open the search box (or hit Ctrl + F / Cmd + F). Enter a string in the search box. This will filter the logs to only show logs that contain the string you entered. You can search through logs by hitting the previous and next buttons, or by hitting Enter to go to the next search result (Shift + Enter to go to the previous search result).

Expanding Context If the Show context logs when filtering option is activated, expanding buttons appear next to matches. Click a button to reveal more lines around the match. Click again to expand further. Changing your search or filters resets the view to collapsed.

Viewing Logs

In order to help make log analysis more efficient, Pipekit automatically helps identify errors by coloring the logs.

Log Level Detection

Pipekit automatically detects and highlights log levels in your workflow logs.

Supported Log Levels

Level	Display	Displayed color	Keywords Recognized
Critical	critical	Purple	emerg, emergency, fatal, alert, crit, critical, panic
Error	error	Red	err, eror, error, fail, failed, failure
Warning	warning	Orange	warn, warning
Info	info	Green	info, information, informational, notice
Debug	debug	Blue	dbug, debug
Trace	trace	Pastel Blue	trace, verbose
Default	unknown	Gray

Supported Log Formats

The detection system recognizes the most common logging formats used in production systems.

JSON Structured Logs

{"level": "error", "message": "Connection failed"}
{"severity": "warn", "msg": "Retry attempt 3"}
{"lvl": "INFO", "event": "User logged in"}

Recognized field names: level, severity, lvl, log_level, loglevel

Key-Value / Logfmt

level=error msg="Connection failed"
severity=warning component=api
loglevel=debug request_id=abc123

Syslog Format

<3>Mar  6 12:00:00 myhost myapp: Connection failed
<27>Error message with facility

The numeric priority value follows RFC 5424: priority = facility × 8 + severity

Severity	Level
0	Emergency
1	Alert
2	Critical
3	Error
4	Warning
5	Notice
6	Info
7	Debug

Bracketed Format

[ERROR] Connection failed
[WARN] Retry attempt 3
[INFO] Server started
[E] Short error format
[W] Short warning format

Timestamp-Prefixed Logs

2024-01-15T10:30:00Z ERROR Connection failed
2024-01-15 10:30:00 WARN Retry attempt
2024/01/15T10:30:00.123+00:00 INFO Server started

Colon-Separated Format

ERROR: Connection failed
WARN: Retry attempt 3
INFO: Server started on port 8080

Pipe-Separated Format

myapp | ERROR | Connection failed
service | WARN | High memory usage

Android Logcat Style

E/MyApp: Connection failed
W/MyService: Retry attempt
I/MainActivity: onCreate called

Plain Text (Fallback)

When no structured format is detected, the system searches for log level keywords anywhere in the message:

Connection error occurred
Warning: disk space low
This is an info message about the system

Detection Priority

When a log line contains multiple potential log levels, the system:

1. Finds all matches from both structured patterns and keyword occurrences

2. Selects the earliest match by position in the line

3. If tied, selects the higher severity level

Example

68:5   warning  Error: Cannot access refs during render
       ^        ^
       |        |
       wins     loses (appears later)

Result: warning (appears at position 7, before Error at position 17)

This ensures that prefixed severity indicators (like linter output or log framework prefixes) take precedence over error keywords that may appear in the message content.

Unrecognized Logs

Logs that don't match any pattern are assigned the unknown level and displayed with neutral styling.

Log Resource Selector

Pipekit supports the Argo Workflows log resource selector as described in this example. By applying this label to Kubernetes resources, logs from these resources will be displayed within Pipekit.

Log Retention

Pipekit stores logs for 1 year. Logs older than 1 year are automatically deleted. If you wish to use a custom log retention period, consider bringing your own logging solution and integrating it with Pipekit.