Skip to main content
When a collector fails in ConfigView, the Last run failed marker on its integration’s page brings you here. The same handful of root causes account for almost every failure — work through the checklist below in order before opening a support ticket.

​
1. Are the secrets filled in?

The most common failure right after enabling an integration is empty secret values. Enabling an integration creates empty secret slots in Google Secret Manager; you have to populate them.
  1. Go to https://{companyname}.configview.com/admin/integrations/
  2. Find the secret(s) required by the failing integration (e.g., LOOKER_CLIENT_ID, AWS_ACCESS_KEY, OKTA_DOMAIN).
  3. Confirm each one has a real value — not the placeholder text.
  4. Click Run now on the failing collector, on its integration’s page, to retry.
If you just rotated credentials, the old values are still cached until you save the new ones here.

​
2. Does the API key have enough permissions?

The second most common failure is a scope/permission shortfall — the credentials are valid, but the API user doesn’t have rights to read what ConfigView is asking for. Each integration documents its required role/scopes on its setup page:
  • Looker — requires the Admin role (some endpoints like scheduled plans, alerts, and SSO configs are admin-only)
  • AWS — requires the IAM actions listed in the policy block on the AWS setup page
  • Okta — requires a read-only API token with the documented admin scopes
  • Google Workspace — requires a service account with delegated admin access
  • See the integration’s page in the left nav for the full list
A common pattern: an integration “mostly works” but a few specific scripts fail. That’s almost always a missing permission for those endpoints, not a broken integration. Compare which collectors failed on the integration’s page against the per-script permission table on its doc page.

​
3. Did the credentials get rotated or expire?

  • API keys rotated in the vendor’s console but not updated under Credentials on the integration’s page
  • Service accounts disabled or deleted
  • OAuth tokens past their refresh window
  • IAM users with attached deny policies added after initial setup
If permissions looked correct yesterday and the script started failing today, check the audit log on the vendor’s side for credential changes.

​
4. Is the integration in a half-enabled state?

If a createdb_*.py script failed during enable, the integration may be partially installed — scripts on disk, tables missing, secrets created but empty. Symptoms: every get_*.py script fails with “table doesn’t exist.” Fix:
  1. Click Disconnect on the integration’s page and confirm.
  2. Investigate the original createdb failure in /admin/activity/.
  3. Reconnect after fixing the root cause (usually a missing permission for CREATE TABLE or a typo in a secret).
See Enabling and disabling integrations for the full lifecycle behavior.

​
5. Is the vendor’s API up?

Rare, but worth a check before assuming the worst:
  • AWS Health Dashboard, GCP Status, Okta status, etc.
  • A 5xx error in the activity log usually means the upstream API is the problem, not your config.

​
Where to find more detail

/admin/activity/ is the authoritative log for every script run. It records the exact HTTP status, error message, and stack trace returned by the failing API. When the buckets above don’t explain a failure, the activity log will.

​
Still stuck?

Email support@configview.com with:
  1. The integration name and the failing script name (e.g., “Looker / looker_get_alerts.py”)
  2. The exact error message from /admin/activity/
  3. The vendor role/scope assigned to the credential
  4. When the failure started (was it ever working, or did it fail from the first run?)
Including all four lets support skip straight to the actual problem.