View logs

A rule match with logging enabled produces a log entry: who requested which package, through which firewall, which rule fired, and whether the request was blocked. Logs are the place to answer "why did this install fail" and "what would this rule have blocked". They are not a record of every request; see What is logged when below.

In the dashboard

Open Logs on a firewall. Each entry shows the timestamp, the block decision, the execution phase (versions, download, or upload), the package and version, the matched rule, and the user. Users appear by name where the dashboard can resolve them; service tokens and removed users show the raw ID. From a log entry you can create an exception directly, prefilled with the rule and package.

Select a row to see the complete entry. The detail includes fields not shown as table columns, such as request, interaction, upstream, and, when applicable, the source firewall or exception.

The newest entries load first. Load more at the bottom of the table fetches the next batch of older entries, so you can page back as far as the retained history goes. New entries arriving while you page do not shift or duplicate the ones already on screen.

From the terminal

The bsfw CLI queries the same logs and prints a compact summary. Use the dashboard row detail or the logs API when you need every field.

export BYTESAFE_ENDPOINT=https://eu-sov-1.bytesafecloud.eu
export BYTESAFE_NAMESPACE="<namespace-id>"
export BYTESAFE_TOKEN=<your token>

bsfw logs --firewall <firewall-id>

Stream live

bsfw logs --firewall <firewall-id> --tail

--tail keeps the connection open and prints entries as they happen. Useful while testing a new rule: run the install in one terminal and watch the decision in the other.

Filter by user

bsfw logs --user user-7d2f...
bsfw logs --all-users

--user and --all-users are mutually exclusive, and --user takes the raw user ID, not a name or email. Omit both to see your own entries.

Correlate CI runs

Log entries record the interaction ID when the token carries one (<token>::<id>, see Access Tokens). Set it to the pipeline run ID in CI and every package request from that run shares the ID.

What is logged when

• A rule with log: true writes an entry on every match, blocked or not. A log-only rule (block: false, log: true) is the standard way to trial a policy before enforcing it.
• An exception with log: true writes an entry when it lets a request through. The complete entry identifies the exception.
• A rule with log: false writes nothing, even when it blocks the request. If an install fails with no entry to show for it, this is the first thing to check.
• Requests that match no rule are not logged at all. An empty log means no rule had anything to say, not that no packages were installed.

To see traffic that no policy rule covers, add a rule matching all packages with { "block": false, "log": true }. That is also the quickest way to confirm a client really is going through the firewall.

Related

• How-to: Investigate a blocked install
• Reference: CLI