Skip to content

Collecting logs

Which logs to include when reporting a problem so we can help quickly.

When you have a problem with CodeCharter, the right logs help us diagnose it faster.

CLI verbose log

The most important data point. Run the problem with --verbose:

codecharter analyze . --verbose 2> codecharter.log

codecharter.log contains:

  • Which configuration was loaded
  • Which rules are active
  • Which solution projects were found
  • Which cache hits occurred
  • Stack traces if something crashes

Attach the file when you write to us.

VS Code extension log

View → Output, select "CodeCharter" from the dropdown, copy the contents.

If the extension was still running during the log, the output is live — trigger "Analyze again" once, then copy the contents.

CI logs

For a CI problem:

  • GitHub Actions: click the workflow run, click "View raw logs", save the contents as a .txt file.
  • GitLab: job detail page, "Show complete raw" in the top right.
  • TeamCity: build detail, "Build Log" tab, "Download".
  • Others: equivalent.

For large logs, a cut around the relevant section plus 20 lines of context is usually enough.

CLI version and system info

codecharter --version
dotnet --info
uname -a              # Linux / macOS
systeminfo            # Windows

Include these as well. They help us narrow down platform-specific problems.

Solution info without sensitive data

# Count projects without revealing paths
find . -name "*.csproj" | wc -l

If you are referring to a specific file, you can extract a minimal repro — the smallest piece of code that shows the problem:

// minimal-repro.cs
using System;

public class Example
{
    public void Demo()
    {
        // The problem occurs here
    }
}

A solution with one project containing this file is all we need. We do not need your real codebase.

Networking logs

If you have problems with the CLI download:

curl -v -H "Authorization: Bearer $CODECHARTER_API_KEY" \
    https://codecharter.tools/api/v1/cli/linux-x64/latest \
    -o codecharter.tar.gz 2> network.log

-v produces the full HTTP trace. Header fields do not contain the API key in plaintext (it appears only once in the Authorization header, which you can replace with Authorization: Bearer ***).

Portal-side logs

If the problem is in the portal (login failing, download aborting), we can look up on our end whether an error occurred. Send us:

  • The approximate time (UTC)
  • The email you were logged in with
  • The browser stack (Chrome 121, Firefox 122, ...)

What we do NOT need

  • Your complete codebase (not even under NDA — we simply do not want it).
  • Plaintext API keys. If a log contains a key, mask it.
  • Plaintext passwords. We only ever see hashes anyway; do not send them.

How to send it all

Email to [email protected] with logs as .txt or .log attachments. If the files are large (several MB), feel free to gzip or zip them.

We typically respond within 24 hours on business days.