> ## Documentation Index > Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt > Use this file to discover all available pages before exploring further. # Set up logging review > Have Sazabi add the log lines a pull request is missing and fix the ones that will not help in production, as suggested changes, an on-demand commit or a batched commit. ## 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](https://docs.sazabi.com/catalogs/integrations/github.md), [Bitbucket](https://docs.sazabi.com/catalogs/integrations/bitbucket.md) and GitCafe, wherever [automated code review](https://docs.sazabi.com/guides/build/automated-code-review.md) runs. > [!WARNING] > > **Limited release** > > Logging 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](https://docs.sazabi.com/guides/administer/support.md) 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](https://docs.sazabi.com/guides/build/automated-code-review.md) 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 **Step 1** ### Open the Code settings In the dashboard, go to [**Settings > Code**](https://app.sazabi.com/settings/code-search). **Step 2** ### Choose a logging review mode Under **Logging review**, pick **Suggest**, **On demand** or **Auto-commit** (see [Choose how changes arrive](#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**: ```bash theme={"system"} sazabi projects code-review --json sazabi projects code-review --logging-review true --logging-review-mode suggest --json sazabi projects code-review --logging-review-mode auto_commit --logging-review-daily-limit 5 --json ``` 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](https://docs.sazabi.com/reference/api.md), 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. | Mode | What Sazabi does | Commits | CI runs | | - | - | - | - | | **Suggest** (default) | Posts each change as a suggested change on the line | You commit them | One, if you apply them together | | **On demand** | Posts one comment listing the changes and how to apply them | Sazabi, when you ask | One per apply | | **Auto-commit** | Commits the changes once the pull request has been quiet for 15 minutes | Sazabi | At most one per round | ### 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**](https://app.sazabi.com/settings/code-search), 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](#when-sazabi-posts-suggestions-instead). ## Further reading > [card] [Set up automated code review](https://docs.sazabi.com/guides/build/automated-code-review.md) > > Have Sazabi review pull requests with inline comments and a verdict. > [card] [Pull requests](https://docs.sazabi.com/guides/build/pull-requests.md) > > How Sazabi opens, reviews, and answers questions on your pull requests. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.