Logs & Errors

Every action in a Crucible-managed engagement is logged. The Log and Errors tabs provide a complete audit trail of what happened, when, and in what order. This is critical for engagement documentation — proving what was tested, when testing started and stopped, and what issues were encountered.

Logs are persisted to the engagement's run directory as scan.log (human-readable) and scan.log.json (machine-readable). Errors are additionally written to errors.log. These files survive Crucible restarts and are included in engagement exports.

The Log tab shows a combined timeline of all events from all managed tools in the engagement.

The Errors tab is a filtered view showing only error-level entries: ERROR, EXCEPTION, TOOL_ERROR, FATAL, and CRITICAL. This provides a focused view of what went wrong without scrolling through thousands of INFO/EVENT lines.

Both the Log and Errors tabs provide From and To datetime pickers at the top of the tab. These filter entries by timestamp:

• From — Show only entries at or after this time. Leave empty for no lower bound.
• To — Show only entries at or before this time. Leave empty for no upper bound.
• Clear Range — Reset both pickers and show all entries.

The filter is inclusive on both ends. This is useful for isolating what happened during a specific testing window — for example, filtering to the exact timeframe when a particular tool was running.

Both the Log tab and Errors tab display a count badge (pill) in the tab header. These badges show the error count only — not the total number of log entries. This applies to both tabs: the Log tab pill shows how many error-level entries exist in the full log, and the Errors tab pill shows the same count.

The error-level classifier matches: ERROR, EXCEPTION, TOOL_ERROR, FATAL, and CRITICAL. INFO, EVENT, and WARN entries do not increment the pill counter.

Pills update in real time as new entries arrive via Socket.IO, and reset to 0 when logs are cleared.

In addition to the combined log view, each managed tool produces its own log files in its run directory:

• scan.log — Human-readable timestamped log (one line per event)
• scan.log.json — Machine-readable JSON log events (JSON array)
• errors.log — ERROR-level entries only

Every third-party tool invocation also produces a .log sibling file (per Section 14) containing the exact command, tool version, start/end time, exit code, full stdout, and stderr. These provide forensic-level detail for each tool execution.

When Engagement Hours are configured (Console tab → Engagement Hours), all start/stop events driven by the schedule are logged:

• Schedule created — Records the allowed testing window (start time, end time, timezone, allowed days)
• Scheduled start — Tools launched by the scheduler at the configured start time
• Scheduled pause — Tools paused when the testing window ends
• Manual override — When the user starts/stops tools outside the scheduled window

This provides a complete timeline of when testing was actively running, which is critical for engagement reporting and dispute resolution.

All logs are persisted to the engagement's run directory on disk. They survive:

• Crucible restarts
• Browser disconnections
• Tool crashes
• System reboots (if the filesystem is intact)

Logs are included in engagement exports (JSON and ZIP). The scan.log.json format is designed for programmatic ingestion by Prometheus and other analysis tools.

In-memory log buffers hold the most recent 2,000 entries for fast UI rendering. The full log on disk has no size limit but may be truncated at display time in the browser for performance.