Data QnA API in Looker Studio Pro returns ACTION_GENERATION_FAILED for all prompts, now working again without changes

Google Cloud Data Analytics
1

Body:
Hello,

Since around 9:30 PM JST on August 12, 2025, our team was unable to use Conversational Analytics in Looker Studio Pro.
For any prompt (even simple ones like “test”), the following error message appeared:

Something went wrong while processing your request. Rephrase your question or try asking something else.

code: 13
message: ACTION_GENERATION_FAILED due to INTERNAL error
domain: dataqna.googleapis.com
traceId: 1524372499576990018

Key points:

  • All project members experienced the same issue.

  • No changes were made to permissions or project settings after it last worked.

  • Tried different browsers, cleared cache — no change.

  • Changed datasource to a test BigQuery table (unrelated to billing) — same issue.

  • No major incidents reported on Google Cloud Status Dashboard.

  • Personalized Service Health only showed a partial Cloud Billing delay (likely unrelated).

  • We are on Basic Support plan, so cannot open a technical support case.

Interestingly, the issue suddenly resolved today without any changes from our side, and now prompts are processed normally.

Could you please confirm if there was any internal service disruption or maintenance affecting Data QnA API or Conversational Analytics in Looker Studio Pro?

Thank you.

Environment:

  • Looker Studio Pro (Conversational Analytics)

  • Data source: BigQuery

  • A specific GCP project (details omitted for security reasons)

1 Like
2

Face the same blip: ACTION_GENERATION_FAILED (code 13) from dataqna.googleapis.com, then it self-resolved. That pattern usually screams transient backend fault or rollout. Nothing to do on the project side.

Check Cloud Logging for dataqna.googleapis.com around your window and correlate with the traceId; you’ll likely see spikes without 4xx.

Our setup: BigQuery + Looker Studio Pro on top of GA4 and Salesforce, modeled in dbt. We hardened the path by keeping a stable, denormalized mart and caching common queries. When Data QnA flakes, we fall back to a direct SQL parameterized report.

Windsor.ai helped by normalizing ad schemas and scheduling dependable loads into BigQuery, so Conversational Analytics isn’t contending with shifting fields. Also cheaper to run vs. building custom connectors, and cronable.

If it happens again: add exponential backoff on QnA calls, monitor API quotas, and keep a SQL runner tile as a fallback. For ingestion, Airbyte’s fine too. Just pin versions to avoid surprise schema drift.

1 Like