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.

We triage three kinds of submissions from this page. They all go to the same inbox — support@configview.com — but each gets routed faster when you label it clearly and include the right context up front.

​
Feature request

Use this when an integration you already have could do more — additional endpoints, columns, filters, or behavior on an existing service. Subject line: [Feature] <integration>: <one-line summary> Examples: [Feature] AWS: pull DynamoDB GSI count, [Feature] Looker: ingest dashboard view counts. Include:
  • Which integration this affects (e.g., Looker, AWS, Okta)
  • What you want to see, in business terms — what question does this help you answer?
  • (Optional) Which API endpoint or report you think it would come from. Helpful but not required — we’ll figure out the mechanics.
  • How urgent it is (nice-to-have vs. blocking a specific compliance or reporting deadline)

​
Integration / application request

Use this when you want ConfigView to support a new vendor entirely (one that isn’t on the integrations list today). Subject line: [Integration] <vendor name>: <use case> Examples: [Integration] Notion: track workspace member access, [Integration] Datadog: ingest monitor configurations. Include:
  • Vendor name and the SaaS surface area you care about (e.g., “Datadog monitors” not “all of Datadog”)
  • The compliance, audit, or operational use case driving the request — this helps us scope the right endpoints
  • Whether your team already has admin/API access to this vendor (so we know setup feasibility)
  • How many of your colleagues would benefit — single-team need vs. company-wide
Integration requests usually take longer than feature requests because they involve new API client code, secret management, doc pages, and a release. Expect a scoping conversation before we commit to a timeline.

​
Bug report

Use this when something is broken or wrong — wrong data in a table, a script that fails consistently, a UI element that doesn’t work as documented. Before filing: check Troubleshooting failed scripts first. The five buckets there account for most apparent “bugs” that are actually configuration issues. Subject line: [Bug] <integration or area>: <symptom> Examples: [Bug] Okta: okta_get_groups.py missing externally_managed column, [Bug] Admin/cron: Save button greyed out. Include:
  • Where you saw it (exact URL, e.g., /admin/cron/, or script name like looker_get_alerts.py)
  • What you expected vs. what actually happened
  • The exact error message from /admin/activity/ if it’s a script failure
  • Steps to reproduce (even if “just enable X and wait”)
  • When it started — has this ever worked? Did it change recently?
  • Screenshots if it’s a UI issue
The more reproducible the report, the faster the fix. A bug that we can reproduce on our side usually ships a fix within one release cycle.

​
How to submit

Email support@configview.com using the subject-line conventions above. We respond within one business day with either a confirmation, a question for more detail, or a triage ticket number. You don’t need to use a form — clear email beats every form we’ve ever tried.

​
What we don’t take here

  • Security disclosures. Use security@configview.com and include the affected URL or script. We treat these with priority and don’t discuss them in public channels.
  • Account / billing questions. Those go to billing@configview.com.
  • “Is my dashboard down?” ConfigView is single-tenant — your instance runs in your own cloud account (GCP, AWS, or Azure). If the dashboard is unreachable or scripts have stopped firing, check your own cloud provider’s status page first (GCP Status, AWS Health Dashboard, Azure Status). A ConfigView code issue would show up as a specific script error in /admin/activity/, not as the whole instance going dark.