Logging and Reporting

Where BootstrapMate writes its log, exactly what a log line looks like, what status it leaves in the registry and on disk, and how to tell a healthy run from a bad one. Read this before you write any monitoring against the tool, because the status surface has a split between where status is written and where it is read.

The log file

One file per run, in C:\ProgramData\ManagedBootstrap\logs, named for the run's start time in local time:

C:\ProgramData\ManagedBootstrap\logs\yyyy-MM-dd-HHmmss.log

Line format

Every line is written by Logger.FormatLine as:

[{timestamp:yyyy-MM-dd HH:mm:ss}] {LEVEL,-5} {message}

Three fields:

timestamp — local time, second resolution, in square brackets.
LEVEL — the level name, left-aligned and padded to a five-character column. That padding is why INFO and WARN are followed by two spaces and DEBUG/ERROR by one.
message — the text, with any ANSI colour escapes stripped.

Real lines:

[2026-09-03 08:14:02] INFO  === BootstrapMate Session Started ===
[2026-09-03 08:14:03] DEBUG Downloading manifest from: https://example.com/bootstrap/manifest.json
[2026-09-03 08:14:07] WARN  MSI error 1603, retrying in 10 seconds... (attempt 1/5)
[2026-09-03 08:14:19] ERROR Failed to install package Example App: Download failed: Forbidden
[2026-09-03 08:14:20] INFO  [OUTPUT] Chocolatey: Installing the following packages:

Levels that reach the file

The logger has five levels — Debug, Info, Warning, Error, Success — but only four level names ever appear in the file. Debug writes DEBUG, Warning writes WARN, Error writes ERROR, and everything else, including Success, writes INFO. A successful install is an INFO line carrying a [SUCCESS] marker in the message, not a SUCCESS level.

The file always receives every level, including DEBUG. --verbose/-v and --silent affect the console and the pipe, never the file.

Classification beyond the level column is carried as a bracketed marker at the start of the message: [SECTION], [PROGRESS], [SUB-PROGRESS], [SUCCESS], [SKIPPED], [COMPLETION], [OUTPUT]. Grep for these rather than for the level.

Captured child output

A package's own output is written back into the same log, one stamped line each, prefixed [OUTPUT] {package}: . Standard output is recorded at INFO and standard error at WARN. This covers PowerShell, EXE and Chocolatey items.

sbin-installer is the exception: its output goes to Logger.Debug as sbin-installer stdout: … and sbin-installer stderr: …. It is still in the file, but it is DEBUG, so it will not show up if you are filtering.

Multi-line messages are split on newline, blank lines are dropped, and every resulting line gets its own timestamp and level.

Retention

Old logs are pruned when the logger initialises, at the start of each run. Any *.log in the log directory whose LastWriteTime is older than 30 days is deleted. Age comes from last-write rather than the filename deliberately, because the directory also collects logs from wrapper scripts that do not use the timestamped name.

Pruning is best-effort: a locked file is skipped and all exceptions are swallowed. Nothing reports a prune failure.

Following a run live

Tail the newest log:

Get-Content (Get-ChildItem C:\ProgramData\ManagedBootstrap\logs -Filter *.log | Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName -Wait -Tail 50

The GUI's Logs tab opens log files with FileShare.ReadWrite, so a run in progress can be read there too, and the Run tab tails the newest log while a run is going. Both viewers colourise by substring — and neither of them matches the WARN the file actually writes, so warnings render as ordinary lines in the GUI. Use the console or the raw file when you care about warnings.

Status surface

Registry — per phase

Written to HKLM\SOFTWARE\Cimian\BootstrapMate\Status\SetupAssistant and HKLM\SOFTWARE\Cimian\BootstrapMate\Status\Userland, in both the 64-bit and 32-bit registry views.

Value	Type	Meaning
`Stage`	REG_SZ	`Starting`, `Running`, `Completed`, `Failed` or `Skipped`. `Skipped` means the manifest had no array for that phase.
`StartTime`	REG_SZ	`yyyy-MM-dd HH:mm:ss` when the phase began.
`CompletionTime`	REG_SZ	Same format; written on terminal stages only.
`ExitCode`	REG_DWORD	`0`, or `1` on a failed phase.
`Phase`	REG_SZ	The phase name, lowercased: `setupassistant` or `userland`.
`Architecture`	REG_SZ	OS architecture, uppercased.
`BootstrapUrl`	REG_SZ	The manifest URL used for this run.
`LastError`	REG_SZ	Exception message, or empty.
`RunId`	REG_SZ	GUID identifying this run.

Phase status keys are cleaned up at startup: any whose CompletionTime is more than 24 hours old, and whose stage is not Running, is removed.

Registry — completion

At the end of a successful ProcessManifest, one value is written to HKLM\SOFTWARE\Cimian\BootstrapMate in both views:

Value	Type	Meaning
`LastRunVersion`	REG_SZ	The BootstrapMate build version that completed the run.

"Successful" here means "no unhandled exception". Individual package failures are caught, so LastRunVersion is written even on a run where every package failed.

Status file

C:\ProgramData\ManagedBootstrap\status.json — an indented JSON dictionary keyed by phase name, rewritten on every status change. It carries the same fields as the registry values.

The registry-path split

Status is written under SOFTWARE\Cimian\BootstrapMate. It is read from SOFTWARE\BootstrapMate. Those are different keys, and the mismatch has direct consequences:

--status reads its "Completion Status" from HKLM\SOFTWARE\BootstrapMate\LastRunVersion, which is written by the MSI at install time, not by a run. It will report a version on a device where BootstrapMate has never completed a run. The "Registry Paths" and "Status File" hints --status prints are pointing at the same wrong locations.
--clear-status deletes SOFTWARE\BootstrapMate\Status\{phase}, a key nothing writes, and the file C:\ProgramData\BootstrapMate\status.json, which is not where the status file lives. The real status under SOFTWARE\Cimian\BootstrapMate\Status and the real C:\ProgramData\ManagedBootstrap\status.json are untouched. It is effectively a no-op.
The shipped Intune detection scripts read the MSI-written key, so they detect the MSI install rather than a successful bootstrap. See Deployment.

Query the real values directly:

Get-ItemProperty 'HKLM:\SOFTWARE\Cimian\BootstrapMate\Status\SetupAssistant'
Get-ItemProperty 'HKLM:\SOFTWARE\Cimian\BootstrapMate\Status\Userland'
Get-ItemProperty 'HKLM:\SOFTWARE\Cimian\BootstrapMate' -Name LastRunVersion

Run summary reporting

If ReportingUrl is set, BootstrapMate POSTs a JSON run summary at the end of the run, from both the success and the failure path. An empty ReportingUrl disables it entirely. The POST uses a 15-second timeout, sends User-Agent: BootstrapMate/{version}, and attaches ReportingHeader as the Authorization header if one is configured. A failing POST never fails the run — it logs Reporting POST failed: {msg} and moves on.

Payload fields: tool, platform, schemaVersion, version, runId, success, startTime, endTime, durationSeconds, architecture, hostname, serialNumber, manifestUrl, and phases — an object keyed SetupAssistant and Userland, each carrying stage, exitCode, startTime, completionTime and lastError.

serialNumber comes from HKLM\HARDWARE\DESCRIPTION\System\BIOS → SystemSerialNumber, and is an empty string when that value is unreadable. success reflects whether ProcessManifest threw, not whether every package installed.

Configure both values through Preferences.

What a healthy run looks like

In the log, in order:

[…] INFO  === BootstrapMate Session Started ===
[…] INFO  Version: <yyyy.MM.dd.HHmm>
[…] INFO  Settings loaded from: Management
[…] INFO  Downloading manifest from: https://example.com/bootstrap/manifest.json
[…] INFO  [SECTION] Processing Setup Assistant packages
[…] INFO  [PROGRESS] Processing: <package>
[…] INFO  [SUB-PROGRESS] Downloading from: https://example.com/pkgs/<file>
[…] INFO  [SUB-PROGRESS] Downloaded: 12.4 MB
[…] INFO  [SUCCESS] <package> installed successfully
[…] INFO  [SECTION] Processing Userland packages
[…] INFO  [COMPLETION] BootstrapMate completed successfully! (Completed: …, Total Duration: 214.7s)

And on the device:

No Failed to install package lines anywhere in that log.
C:\ProgramData\ManagedBootstrap\cache is empty. A cached file is deleted on a successful install and kept for inspection on a failure, so any file in there is a failed install.
Stage is Completed (or Skipped for a phase your manifest omits) under both HKLM\SOFTWARE\Cimian\BootstrapMate\Status\SetupAssistant and ...\Status\Userland.
LastRunVersion is present under HKLM\SOFTWARE\Cimian\BootstrapMate.

The session-ended terminator you might expect is not written; [COMPLETION] is the last line of a successful run.

Uh oh!

Logging and Reporting

Logging and Reporting

The log file

Line format

Levels that reach the file

Captured child output

Retention

Following a run live

Status surface

Registry — per phase

Registry — completion

Status file

The registry-path split

Run summary reporting

What a healthy run looks like

See also

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Introduction

The Manifest

Configuration

Operations

More

Clone this wiki locally