Skip to main content

About

Logging review is a separate pull request review that looks only at logging. On each pull request it adds the log lines a change is missing and fixes the ones that will not help when something breaks in production, written the way your repository already logs. You choose how the changes arrive: as suggested changes, as one commit when you ask for it, or as one commit Sazabi pushes once you stop pushing. Logging review is production-aware: it reads how often the log lines a change touches fire in your project’s production logs, and the Sazabi issues linked to the pull request, and uses them to decide what matters. It works on GitHub, Bitbucket and GitCafe, wherever automated code review runs.
Limited releaseLogging review is currently in limited release and is not yet enabled for every organization. Until it is enabled for yours, the Logging review setting does not appear. Contact support to request access.

What it suggests

Logging review only comments on lines the pull request adds or changes.
  • Missing log lines. A caught error that is swallowed or ignored, an outbound call (HTTP, database, queue, third-party SDK) with no record when it fails, a background job, retry or fallback that runs silently, and new log lines that leave out the request or job identifier in scope.
  • Log lines to fix. Values interpolated into the message instead of passed as fields, the wrong level, debug leftovers such as console.log, the same error logged twice, secrets, personal data or whole payloads in a log line, and a log line in a hot loop.
Each pull request gets at most five changes, the most important first. Logging review never approves, never requests changes and never blocks a merge. It pushes a commit only in the on-demand and auto-commit modes.

Prerequisites

  • Automated code review set up for the project: the repositories mapped to it and the integration’s own review setting on.
  • Project settings:write to change the setting.

Set up in the dashboard

1

Open the Code settings

In the dashboard, go to Settings > Code.
2

Choose a logging review mode

Under Logging review, pick Suggest, On demand or Auto-commit (see Choose how changes arrive). It is Off by default and applies to the project you have selected, so repeat it for each project. Logging review has its own setting: turning code review on or off does not change it.

Set up with the CLI

Logging review has no connect command; it is a project setting. Read or change it with sazabi projects code-review, which needs project settings:write:
Modes are suggest, on_demand and auto_commit; the daily limit is 1 to 100, or none. Without a setting flag the command only reads. The same settings are projects.codeReviewSettings.get and projects.codeReviewSettings.update in the API, and the logging_review_* attributes of the sazabi_project_code_review Terraform resource. In suggest and on-demand modes, logging review runs when a pull request is opened, and again on new commits when Automatically review new changes is on for code review. Auto-commit runs on its own schedule, described below.

Choose how changes arrive

Every mode runs the same review and finds the same changes. The difference is who commits them, and so how often your CI runs again.

Suggest

Changes arrive as suggested changes on the lines they touch. On GitHub, to apply several in one commit, and one CI run, click Add suggestion to batch on each one, then Commit suggestions. Bitbucket shows an Apply suggestion button on each one in its web UI. GitCafe has no suggested changes, so each one is posted as a code block to copy.

On demand

Sazabi keeps one comment on the pull request that lists the pending changes, with the reason and code for each. To apply them all as one commit, comment @Sazabi logs apply; on GitHub you can also tick Apply all logging changes (one commit) in that comment. On GitHub, anyone who can push to the repository can apply them. On Bitbucket and GitCafe, only the pull request’s author can, through the command. The comment is updated after each review. If you pushed since the changes were written, Sazabi does not apply them; it notes why in the comment (and unticks the box on GitHub) and refreshes the list with its next review, or right away if you comment @Sazabi logs.

Auto-commit

Sazabi commits the changes itself, batched so your CI does not run again after every push:
  • It waits until the pull request has had no new commits for 15 minutes; every push restarts the wait. This applies to every new commit, whatever Automatically review new changes is set to.
  • It skips draft pull requests and starts when one is marked ready for review.
  • It pushes at most one commit per round, chore(logging): Sazabi logging review (N changes), and never reviews its own commit.
  • If you push while it is committing, it commits nothing and waits for the pull request to go quiet again. It never force-pushes and never adds [skip ci], so required checks still run.
  • You can set a Daily commit limit per repository. Once it is reached, later rounds that day post suggested changes instead.
Each round’s comment links the commit, so you can review or revert it like any other.

When Sazabi posts suggestions instead

The on-demand and auto-commit modes fall back to suggested changes, with a one-line note in the comment, when Sazabi cannot commit:
  • the pull request comes from a fork;
  • branch protection, a ruleset or a branch restriction rejects the commit, or Sazabi’s access to the forge cannot write to the branch;
  • a change reaches outside the lines the pull request changes;
  • the daily commit limit is reached.
All three modes work on GitHub, Bitbucket and GitCafe, and Sazabi commits on all three. A commit keeps each file’s executable bit.

Trigger a review with @Sazabi logs

To ask for a logging review at any time, comment @Sazabi logs on the pull request. In auto-commit mode it runs right away and commits without waiting. @Sazabi review asks for a code review only, and @Sazabi logs apply applies pending on-demand changes.

Match your team’s conventions

Logging review follows the logger, call style and field names your repository already uses. To give it explicit rules, add a .sazabi/logging.md file to the repository: for example, which fields every log line must carry, which levels to use for what, or what must never be logged. A logging section in AGENTS.md or CLAUDE.md is read too.

Billing

Each logging review counts as one pull request review toward your plan’s review usage, the same as a code review. Applying on-demand changes and auto-commits are not billed separately.

Verify

With logging review on, comment @Sazabi logs on a pull request that changes code with an empty catch block or an unlogged outbound call. Confirm Sazabi posts a review with a suggested change within a few minutes.

Troubleshooting

No logging review posted. Check that Logging review is on in Settings > Code, that the repository is mapped to this project, and that the integration’s own review setting is on. No suggestions on a review. Logging review comments only when it finds something worth changing; a review that says the logging looks fine is expected on many pull requests. Didn’t re-run on a new commit. Turn on Automatically review new changes, or comment @Sazabi logs. In auto-commit mode, Sazabi waits until the pull request has had no new commits for 15 minutes. Applying the changes did nothing. On GitHub, only someone who can push to the repository can apply changes; on Bitbucket and GitCafe, only the pull request’s author can, by commenting @Sazabi logs apply. If the pull request has new commits since the review, Sazabi says so in the comment (and unticks the box on GitHub); comment @Sazabi logs to refresh the changes. Sazabi posted suggestions instead of committing. The note in Sazabi’s comment gives the reason; see When Sazabi posts suggestions instead.

Further reading

Set up automated code review

Have Sazabi review pull requests with inline comments and a verdict.

Pull requests

How Sazabi opens, reviews, and answers questions on your pull requests.