Retool OAuth2 Custom Domain Failure: What the Data Shows

Where these brands stand in our index

These figures come from a fixed panel of prompts re-run on a schedule, most recently on 2026-07-28. The measurement is independent of this event: any position or movement shown here is reported alongside the event, not caused by it, and we make no causal claim between a single event and a panel measurement.

Who reported it, and when we saw it

Key facts

• Retool identified the OAuth2 custom domain authentication issue at 17:05 UTC on 25 March 2026 and marked it resolved at 20:36 UTC, an interval of 3 hours 31 minutes.
• Corroboration for the event is 1: the only source is Retool's own incident channel (inc_retool).
• Retool scores 4.2 visibility at rank 17 in the SaaS & AI Tools AI Visibility Index, measured 28 July 2026.
• Retool's per-engine share is 8.3 on OpenAI and 0.0 on Perplexity.
• Commercial intent on queries naming Retool is 62; the brand sits in the Low performance quadrant with a delta of 0.0.
• DABYTE assigns the event a decision-relevance window of 336 hours.

What Retool reported

Retool logged an incident affecting the OAuth2 resource authentication flow on Retool Cloud, specific to custom domains, on 25 March 2026. The published timeline shows two states: an entry at 17:05 UTC marking the cause identified with a fix in progress, and an entry at 20:36 UTC marking the incident resolved. The interval between those two posts is 3 hours and 31 minutes. Retool did not disclose the root cause, the number of affected organisations, the regions involved, or whether authentication tokens issued during the window needed to be reissued. OAuth2 resource authentication is the mechanism Retool applications use to connect to external data sources on a user's behalf, so a failure in that flow blocks resource connections rather than the Retool editor itself — though Retool did not describe the user-facing symptom in the notice DABYTE recorded. No compensation, credit, or post-incident report was referenced in the status entries.

Corroboration count is one

Corroboration for the Retool OAuth2 event stands at 1. The single source is inc_retool, Retool's own incident and status channel. No independent publication, competitor status aggregator, or trade outlet in DABYTE's monitored set carried the same event. A corroboration count of 1 with a first-party source means the facts are authoritative on what happened but unverified on scope: the vendor controls both the description and the severity label, and there is no external account of how many customers noticed. For readers building automated monitoring, that matters. First-party-only events are the most common class of infrastructure disclosure and the least likely to be picked up by AI answer engines, because engines weight sources that appear in multiple places. An incident with corroboration of 1 rarely enters the training or retrieval surface that shapes what an assistant says about a vendor's reliability.

Retool's position in the index

Retool holds a visibility score of 4.2 and rank 17 in DABYTE's SaaS & AI Tools AI Visibility Index, measured 28 July 2026. The score is the share of AI-generated answers in which Retool is named across the two engines DABYTE queries. The per-engine split is uneven: 8.3 on OpenAI and 0.0 on Perplexity. Retool's delta since the previous measurement is 0.0, meaning no movement in either direction. DABYTE places Retool in the Low performance quadrant. Commercial intent on the queries where Retool surfaces is 62, indicating that a majority of the prompts that name Retool are evaluation- or purchase-shaped rather than purely informational. The combination — a mid-table rank, meaningful buyer intent, and zero presence on one of two engines — describes a brand whose AI-channel exposure depends almost entirely on a single retrieval pipeline.

Why the Perplexity zero matters

Perplexity returns Retool in 0.0% of the measured answers, against 8.3% on OpenAI. A hard zero on one engine is a different problem from a low score. Low scores respond to content and mention volume; a zero suggests Retool is absent from the citation pool that engine draws on for the query set DABYTE runs, which includes commercially framed prompts at intent 62. For an incident like the OAuth2 custom domain failure, the consequence is asymmetric. Anyone asking an OpenAI-backed assistant about Retool's reliability draws on a retrieval surface where Retool appears; anyone asking Perplexity gets answers built without Retool named at all. Status-page events with corroboration of 1 do not change either figure on their own, and Retool's delta of 0.0 confirms no measured movement. Closing a per-engine zero requires third-party coverage, not first-party notices.

How long this stays decision-relevant

DABYTE assigns the Retool OAuth2 event a shelf life of 336 hours, or 14 days, from the 25 March 2026 report date. Resolved single-incident authentication failures decay quickly as decision inputs: once the fix ships and no follow-up notice appears, the event stops informing procurement questions and becomes background. Within that 336-hour window, the event is legitimately usable in two contexts — reliability diligence on Retool Cloud's OAuth2 path for custom domains, and incident-frequency tracking for teams that log vendor status history. Outside the window, the useful residue is the index position rather than the outage: visibility 4.2, rank 17, OpenAI 8.3, Perplexity 0.0, commercial intent 62, delta 0.0 as of 28 July 2026. Those figures move on a measurement cadence, not an incident cadence, and DABYTE does not treat a single resolved status entry as evidence of a reliability trend.

Questions this answers

Machine access

• /api/articles.json — every piece we published, with the measurement each one rests on
• /api/aiv.json — the AI Visibility Index the numbers above come from
• How the index is measured