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.

ConfigView gives you per-integration control. Checking an integration at /admin/cron/ installs everything needed to pull its data; unchecking removes it cleanly. This page explains exactly what happens at each step so you know what to expect — and what’s preserved if you re-enable later.

​
Enabling an integration

When you check the box for an integration (e.g., AWS) at https://{companyname}.configview.com/admin/cron/ and click Save, ConfigView does the following, in order:
  1. Creates empty secret entries in your Google Secret Manager for every secret the integration needs (e.g., AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION for AWS). You’ll fill in the actual values at /admin/secret/.
  2. Copies the integration’s scripts from ConfigView’s master repository into your runtime directory.
  3. Creates the database tables by running every createdb_*.py script for the integration.
  4. Schedules every recurring script at your configured default time (set the default once at the top of /admin/cron/ — see Schedules).
  5. Triggers an immediate one-shot first run so data starts populating within minutes instead of waiting until the default time.
If any createdb script fails (most commonly because of a missing IAM action or a typo in a secret), the integration is not added to your selection. ConfigView keeps the partial state (scripts on disk, secrets created) so you can investigate the failure in the activity log at /admin/activity/. After fixing the root cause, toggle the integration off and back on.
After you enable an integration, fill in the secret values immediately at /admin/secret/. The first one-shot run will fail with permission errors if the secrets are empty — that’s normal. Once secrets are correct, click Run Now on any script in /admin/cron/ to retry, or wait for the next scheduled fire.

​
Disabling an integration

When you uncheck the box and click Save, ConfigView removes the integration in this order:
  1. Pauses every script for the integration (scheduler.remove_job + database flag flipped to inactive).
  2. Drops the integration’s tables by running every dropdb_*.py script.
  3. Removes the scripts from your runtime directory (the master repository copy is unaffected).
  4. Deletes the secret entries from Google Secret Manager.
Disabling an integration drops all of its tables and data. Historical rows are not preserved. If you want to keep the historical data but pause new collection, do not disable the whole integration — instead, use the Stop button on each individual script. That pauses the schedule without dropping tables.
If any dropdb script fails, the integration is kept selected to give you a chance to inspect what went wrong. Scripts that did succeed are reflected — meaning some tables may already be gone — but the schedule is paused and secrets are preserved until the operation completes cleanly. Fix the underlying issue (usually a permissions change or a manual table rename) and try disabling again.

​
What’s preserved if you re-enable

When you re-enable an integration you previously disabled, ConfigView restores any per-script schedule overrides you had made. For example, if you had set the AWS Lambda inventory script to run at 2:00 PM (instead of the default time), that 2:00 PM schedule comes back when you re-enable AWS — you don’t have to set it again. Tables and data are not restored — re-enabling re-creates the tables empty and triggers fresh first runs. Use this for:
  • Temporary pauses during infrastructure migrations
  • Onboarding test cycles in non-production environments
  • Switching credentials (disable, rotate the IAM user, re-enable with new keys)

​
What’s preserved if scripts ship in a future update

The master scripts repository updates automatically every 5 minutes. When new scripts arrive in a folder you already have enabled:
  1. The new scripts are copied into your runtime directory.
  2. Any createdb scripts for the new tables run automatically.
  3. Any new get scripts are scheduled at your default time with no action required from you.
This is how ConfigView ships new features (e.g., a new AWS service inventory) without making you re-do setup.

​
At-a-glance summary

WhatOn enableOn disableOn re-enable
Secret entriescreated (empty)deletedcreated again
Database tablescreateddropped (data lost)re-created empty
Schedulesset to defaultpaused (preserved)restored at previous time
Scripts on diskinstalledremovedre-installed
Activity log entriesone per stepone per steppreserved across cycles

​
Common questions

Can I disable an integration to save costs without losing data? No — disabling drops all tables. Use the per-script Stop button to pause individual scripts without dropping anything. If I have hundreds of scripts and want to disable one for a week, do I have to click each one? Use the per-script Stop button. Bulk pause/resume per folder is on the roadmap. Does re-enabling re-fetch all historical data? No. Each integration pulls a service-defined window (e.g., AWS Cost Explorer pulls the last 30 days). Whatever the integration pulls naturally, you get on re-enable. What happens to my saved queries when I disable an integration? The saved queries themselves are preserved at /admin/app/. They will return empty results until you re-enable the integration and tables refill.