Schedules

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/integrations/
2. Click Default run time in the top-right of the page.
3. Pick an hour and minute in your local time.
4. Click Save.

That’s it. Every collector you’ve already connected — and every collector that arrives in future ConfigView updates — will run at this time unless you explicitly override it below.

​

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. Open the integration that owns it at /admin/integrations/.
2. Under Collectors, click Edit schedule on the collector’s row.
3. Choose a mode — Daily At a specific time, or Every N days/hours/minutes — and click Start schedule. If it is already running, stop it first; a live schedule cannot be edited in place.

Per-collector overrides are independent of the default. Changing the default later does not overwrite anything you’ve manually set.

​

What happens when you connect an integration

When you click Connect on an integration’s page, 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 collector the integration declares.
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 collector — no need to reconnect the whole integration.

​

What happens when new scripts ship

ConfigView’s master scripts repository updates roughly once per release. When a new collector lands in an integration you’ve already connected:

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 pause a collector without losing its configured schedule:

• Click Edit schedule on its row, then Stop schedule.
• The cron job is removed from the active scheduler but its cron_job row is preserved.
• Reopen the dialog and click Start schedule to resume.

To stop an entire integration (e.g., during an infrastructure migration), click Disconnect on its page. This pauses every collector and drops the corresponding tables. Reconnecting re-creates the tables and re-registers the schedules.

​

Troubleshooting