Error monitoring in Retool, without a log leaving the region
A regulated client needed production error monitoring. Its data residency rules ruled out the usual tools.
See what we builtA claimant fills in a long form on a client portal, submits it, and sees nothing wrong. Their session had lapsed partway through, and the queries behind the form had stopped running. When they signed back in, everything they had entered was gone. The development team heard about it from a support ticket.
The client is a regulated enterprise running client-facing portals on Retool. The portals handle claimant and user data under Canadian data residency rules. Error data, including call stacks and query parameters, has to stay in Canada.
Before: errors arrived as complaints
The team had no automated signal between an error firing and someone noticing. A failed query surfaced when a user reported it. A failed background workflow surfaced when a developer opened its run history and read it step by step, or when bad data turned up downstream.
The costly failures were the quiet ones. The session problem above did not break the screen. The portals had a one-hour session limit, and once it passed, users could keep typing into forms whose queries no longer ran. Nobody could say when the session had lapsed or how many submissions were lost.
Why the usual monitoring tools were out
The standard answer is a hosted service such as Sentry or Datadog. For this client, that would have sent error context, including user-related query parameters, to servers outside Canada. The residency rules did not allow it.
The same constraint applies to any team whose queries carry personal data, financial records, or protected user data. The monitoring has to live where the data already lives.
What we found one level down
Everything a monitor needs was already inside the client's Retool deployment. Retool Events can trigger a workflow when something happens in an app. Retool Workflows can process and route an alert. Retool Database can store the records, behind the same access controls as the apps. No external service had to sit in the path.
What we built
We built Errordrop, Stackdrop's own error monitor for Retool, and deployed it inside the client's environment.
Capture
When a query fails in an app, Errordrop captures a snapshot of the query state and its metadata and sends it to a processing workflow. App errors need no setup beyond connecting the app.
Workflow errors take one extra step. A developer adds a global error handler to each workflow they want monitored, set to trigger the reporting workflow on failure. To record the failing block's name, they wrap the JavaScript or Python block in a try/catch and pass the name in the catch.
Alerts
The processing workflow logs each failure by type and posts a notification to Slack or Teams. Each alert carries the app name, error message, environment, origin, plugin, error type, occurrence count, and timestamp, with a link to the issue page. A configurable cooldown batches repeat occurrences into a count, so a recurring error does not send one alert per occurrence.
The issue page
Each issue shows the error message, a fingerprint, and event and user counts. Below that sits one row per occurrence:
App errors: timestamp, user, browser, operating system, and status code. Expanding a row shows the failing query and its parameters.
Workflow errors: timestamp, run ID, error type, and execution time. Expanding a row shows the stack trace, the failing query text, and the raw error output.
Trend charts and breakdowns by browser, operating system, block, and error type show whether a problem affects one user or a wider pattern.
A lifecycle the developer controls
An issue opens when it first fires. A developer resolves it with a click, and their name, the time, and an optional note are recorded. Reopening is manual too. During the session fix, the error kept firing while the team worked on the cause. An automatic reopen on every occurrence would have buried the signal in noise.
Cost to run
App errors trigger the processing workflow through a Retool Event, and runs triggered by Retool Events do not count toward the monthly workflow quota. Workflow errors are reported by another workflow, which does count. Teams monitoring high-volume workflows should plan for that.
What changed
Failures now reach the development team as alerts, not as support tickets. App and workflow errors land in one dashboard, with the same notification shape, across every portal and environment connected to it. Every error record, call stack, and occurrence log stays in Retool Database, inside the client's region, under the access rules that already protect the portals.
The session problem now appears as an issue with a count and a history, not as a complaint. Errordrop is deployed as part of a Retool build or an engagement to run one, rather than sold separately.
For the controls a reviewer will ask about next, see the security and compliance checklist.
Sound familiar? We have met that one
Before we quote, an hour with the people who run the current process. You hear back within two business days.