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.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.
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
- Go to
https://{companyname}.configview.com/admin/cron/ - At the top of the page, find the Default run time for newly added scripts card.
- Pick an hour and minute in your local time.
- Click Save default.
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:- On
/admin/cron/, expand the integration folder containing the script. - Find the script row and toggle to your desired mode (cron at a specific time, or interval every N minutes/hours).
- Click Save on that row.
What happens when you enable an integration
When you check an integration at/admin/cron/ and click Save, ConfigView does five things in sequence:
- Stores secrets in Google Secret Manager (e.g.
AWS_ACCESS_KEY). - Creates database tables by running the integration’s
createdbscripts. - Registers a recurring schedule at your default time for every
getscript in the folder. - Queues a one-shot first run of each script so data starts populating within minutes, not the next day.
- Reports success in the activity log at
/admin/activity/.
What happens when new scripts ship
ConfigView’s master scripts repository updates roughly once per release. When a newget script lands in a folder you’ve already enabled:
- The master-scripts sync (running every 5 minutes in the background) detects the new file.
- It copies the script into your runtime directory and runs the matching
createdbto create the new table. - It automatically registers the script at your default run time — no per-script click required.
- The script will fire at the next scheduled time (or sooner if jitter places it earlier in the window).
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_jobrow is preserved. - Click Start to resume.
/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
| Symptom | Likely cause | Fix |
|---|---|---|
| Tables exist but never populate | Schedule 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 rows | IAM policy missing an action the script calls | Check 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 / Mar | DST 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 errors | Should not happen — jitter is built in | Confirm jitter=600s in scheduler logs. Report if you see synchronized firing. |