Skip to main content

Documentation Index

Fetch the complete documentation index at: https://support.configview.com/llms.txt

Use this file to discover all available pages before exploring further.

When a script fails in ConfigView, the Failed status link on /admin/cron/ 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/secret/
  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 script at /admin/cron/ 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 scripts failed on /admin/cron/ against the per-script permission table on the integration’s doc page.

​
3. Did the credentials get rotated or expire?

  • API keys rotated in the vendor’s console but not updated in /admin/secret/
  • 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. Uncheck the integration at /admin/cron/ and save.
  2. Investigate the original createdb failure in /admin/activity/.
  3. Re-enable 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.