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 runs your integration scripts on a recurring schedule and stores the results in your database. This page explains how to set a default time, override individual scripts, and what to expect when new scripts arrive in a future update.

Default run time

Every integration script needs to know when to run. Rather than asking you to set a time per script — which becomes painful when an integration ships 50+ scripts — ConfigView lets you set one default that applies to every newly added script across every integration.

Where to set it

  1. Go to https://{companyname}.configview.com/admin/cron/
  2. At the top of the page, find the Default run time for newly added scripts card.
  3. Pick an hour and minute in your local time.
  4. Click Save default.
That’s it. Every script you’ve already enabled — and every script that arrives in future ConfigView updates — will run at this time unless you explicitly override it below.
The time is stored in UTC. The picker shows your browser’s local time. Daylight Saving Time transitions will shift your local-time fire by one hour twice a year; explicit timezone-aware scheduling is on the roadmap.

Jitter

ConfigView spreads jobs scheduled at the same minute across a 10-minute window. So if 200 scripts are all set to 8:00 AM, their actual fires happen between 8:00 and 8:10 instead of literally at the same instant. This prevents cloud-provider rate limits and database connection spikes — you don’t need to manually stagger anything.

Overriding a single script

If a specific script needs a different cadence — say, an hourly findings sync, or a weekly slow scan — you can override its schedule:
  1. On /admin/cron/, expand the integration folder containing the script.
  2. Find the script row and toggle to your desired mode (cron at a specific time, or interval every N minutes/hours).
  3. Click Save on that row.
Per-script overrides are independent of the default. Changing the default later does not overwrite anything you’ve manually set.

What happens when you enable an integration

When you check an integration at /admin/cron/ and click Save, ConfigView does five things in sequence:
  1. Stores secrets in Google Secret Manager (e.g. AWS_ACCESS_KEY).
  2. Creates database tables by running the integration’s createdb scripts.
  3. Registers a recurring schedule at your default time for every get script in the folder.
  4. Queues a one-shot first run of each script so data starts populating within minutes, not the next day.
  5. Reports success in the activity log at /admin/activity/.
If the first run fails (typically because secrets are wrong or the IAM policy is missing actions), the activity log captures the error. Fix the underlying issue and click Run Now on the affected script — no need to re-enable the whole integration.

What happens when new scripts ship

ConfigView’s master scripts repository updates roughly once per release. When a new get script lands in a folder you’ve already enabled:
  1. The master-scripts sync (running every 5 minutes in the background) detects the new file.
  2. It copies the script into your runtime directory and runs the matching createdb to create the new table.
  3. It automatically registers the script at your default run time — no per-script click required.
  4. The script will fire at the next scheduled time (or sooner if jitter places it earlier in the window).
This means new ConfigView features show up in your dashboard as new tables, on the same schedule as everything else, with zero manual setup.

Pausing and resuming

To temporarily disable a script without losing its configured schedule:
  • Use the Stop button on the script’s row.
  • The cron job is removed from the active scheduler but its cron_job row is preserved.
  • Click Start to resume.
To disable an entire integration (e.g., during an infrastructure migration), uncheck the folder at the top of /admin/cron/. This pauses every script in the folder and drops the corresponding tables. Re-checking the folder re-creates the tables and re-registers the schedules.
Uncheck-and-recheck will drop and recreate the tables, which means historical run_at data inside those tables is lost. If you’re disabling temporarily to skip a maintenance window, stop the individual scripts instead.

Troubleshooting

SymptomLikely causeFix
Tables exist but never populateSchedule was never registered (script pre-dates default-schedule feature)Backend migration auto-backfills — restart of backend completes it. Or manually run Run Now.
Script silently returns 0 rowsIAM policy missing an action the script callsCheck activity log at /admin/activity/. Look for AccessDenied messages and add the missing action to your IAM policy.
Script runs at the wrong wall-clock time after Nov / MarDST transition (schedule is UTC-anchored)Adjust the default for the new season, or override the affected scripts.
Two scripts firing at the same instant cause errorsShould not happen — jitter is built inConfirm jitter=600s in scheduler logs. Report if you see synchronized firing.