> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt # Check whether the fix held – Error Tracking pocket guide Canonical URL: https://posthog.com/learn/error-tracking/pocket-guide/verify-the-fix > **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links). ## On this page - [What the scout looks at](#what-the-scout-looks-at) - [The report in your inbox](#the-report-in-your-inbox) - [The scout itself](#the-scout-itself) - [Add this to your scout troop](#add-this-to-your-scout-troop) The Inbox validation scout checks each fix once it has reached guests, and reports the fixes that didn't hold. It waits and compares rates first, because some browsers keep running the old code for a while. ## What the scout looks at Three days ago at 10:30, the engineers merged a fix for the Trip details `TypeError`. The issue still fires at about the rate it did before the merge, so the scout reports it Fig. 1. When the rate fell hard and keeps falling, the fix is still rolling out, and the scout checks again later. 10:30 fix merged Trip details sessions steady Exceptions 312 before, 296 after Fig. 1 – What the scout saw: The fix merged at 10:30. In the 72 hours after, Trip details sessions held steady and the issue fired at nearly the rate it did in the 72 hours before. ## The report in your inbox A fix that didn't hold becomes a new [report](https://posthog.com/docs/self-driving/reports.md) in the team's [inbox](https://posthog.com/docs/self-driving/inbox.md), linked to the original so the team can see what was already tried Fig. 2. P21Trip details TypeError still fires at its pre-fix rate three days after the fix merged 2Three days after twig.com#4891 merged, the Trip details TypeError fired 296 times for 38 guests, against 312 times for 41 guests in the 72 hours before3Scout · inbox validation4ReadyActionable52h ago ArchiveReview6 Fig. 2 – This follow-up report card lands in Twig's inbox. It shows the scout's claim and triage, and the evidence is inside the report.Hover over the figure to learn about each element. ## The scout itself PostHog maintains this scout, listed as **Inbox validation** in the project's scouts. Its [skill file](https://github.com/PostHog/posthog/blob/master/products/signals/skills/signals-scout-inbox-validation/SKILL.md) is on GitHub. It waits 24 hours after the merge for a server fix, and 72 hours or more for web and mobile. Then it compares the issue's exceptions and affected users with the same window before the merge. It also checks Twig's overall traffic, so a quiet weekend doesn't pass for a fix. For a fix no report links to, the [PR follow-up](https://posthog.com/learn/error-tracking/pocket-guide/deploy-regressions.md) scout runs the same check. It runs every 24 hours by default and stays quiet unless something needs the team's attention. ## Add this to your scout troop PostHog ships this scout turned on, and the engineers can turn it off for each project. It checks a fix once exceptions reach PostHog and the fix's report resolves, either when its linked pull request merges or when the engineers resolve it themselves. [Open your scouts](https://app.posthog.com/inbox/scouts)Find Inbox validation in the list and check it's on. See also: [Scouts](https://posthog.com/docs/self-driving/scouts.md) · [Scout examples](https://posthog.com/docs/self-driving/scout-examples.md) · [Reports](https://posthog.com/docs/self-driving/reports.md) · [Managing issues](https://posthog.com/docs/error-tracking/managing-issues.md)