Learn Qourby from first setup to operational triage.
This guide is written for operators who want to add a site, verify ownership, launch scans, interpret results, and automate repeatable workflows without hunting through the product.
Add and verify a production domain with DNS TXT or HTML proof of ownership.
Choose the right profile for low-friction monitoring or deeper active assessment.
Move from raw findings to ownership, evidence review, remediation, and retest.
Quickstart
Start with one verified production asset.
The fastest path through Qourby is to add a real production site, verify ownership, and launch a Standard scan. That gives you enough surface area to see findings, scan history, and evidence without over-scoping your first run.
Add the site you own
Create a monitored asset with its production domain, verification method, and any scan targeting notes.
You can start from the Sites page or launch from the Scans flow when a site already exists.
Verify ownership
Use DNS TXT or HTML verification so the workspace can scan under your approved scope.
Verification status is shown on the site record and reused for future scans.
Choose a profile and launch
Select the scan profile based on the level of depth you want and the expected runtime.
Passive and Light are edge-driven. Standard and Deep use the active scanner pipeline.
Triage findings
Review findings by severity, asset, status, and owner. Evidence is attached to each finding where available.
Use the findings screen for assignment, dismissal, retest, and status changes.
Launch Scan
Centered staged flow from the live product
Selected asset
Customer Portal
portal.acme-health.io
Before you launch
- Ownership verified
- Scope paths saved
- Estimated runtime: 9 minutes
Ownership
Verify scope before active scanning.
Verification is how Qourby keeps scan scope tied to assets you control. Passive checks are useful early, but a verified asset gives your team a cleaner and safer path into repeatable monitoring.
Add a TXT record to the root or delegated verification label, wait for propagation, then re-run verification from the site record.
Type: TXT
Name: _qourby-verify.portal
Value: qourby-verification=8f39f90d2f74470ca6dd
TTL: AutoUpload the provided HTML file to the exact path shown in the UI. Qourby checks for the token and marks the asset verified once the file is accessible.
GET https://portal.acme-health.io/.well-known/qourby-verification.html
Expected body:
qourby-verification=8f39f90d2f74470ca6ddVerification checklist
Use the production hostname you actually want to monitor.
Keep include and exclude paths tight for sensitive flows.
Re-run verification after DNS changes or ingress changes.
Treat staging and production as separate assets when behavior differs.
Profiles
Choose scan depth based on your operational goal.
Profiles are designed around different levels of impact, runtime, and expected coverage. Start with Standard for most product teams. Use Deep when you are intentionally spending more time and scanner capacity on a narrower target.
Practical profile selection
Daily monitoring
Use Passive or Light on important public assets so you continuously catch configuration drift.
Release validation
Use Standard before or after major releases to combine low-noise worker checks with active verification.
Focused investigation
Use Deep when an asset is high risk, high change, or needs closer manual follow-up.
Operations
Turn raw findings into a repeatable triage flow.
The findings workspace is where teams sort by severity, assign ownership, inspect evidence, and move findings through investigation and remediation. The fastest teams standardize a few simple states and enforce them consistently.
Findings Triage
Review, assign, dismiss, and retest from the findings workspace
Unresolved findings
Filtered to Production · High confidence · Open or Investigating
SQL injection via query parameter
portal.acme-health.io
Owner
Alex Chen
Missing HSTS on auth edge
auth.acme-health.io
Owner
Platform Team
Credentialed CORS reflection
api.acme-health.io
Owner
Backend Team
Suggested status model
- Open: new and unassigned
- Investigating: someone is confirming scope, impact, or exploitability
- Resolved: fixed and waiting for confirmation
- Dismissed: false positive, accepted risk, or out of scope with a note
Evidence review
Every meaningful triage decision should connect back to captured evidence. Review the endpoint, request shape, headers, response behavior, and scan timestamp before you assign severity or dismiss a finding.
FAQ
Answers to the common operational questions.
These are the questions teams usually ask after the first successful scans: when scans queue, what partial results mean, and how to think about ownership, scheduling, and automation.
Why is a scan blocked or scheduled instead of starting immediately?
Scans can wait for the next allowed scan window, a verification state, or queue availability. The scan record shows the current step and message so operators can see what is happening.
What happens when a WAF is detected?
Qourby completes the scan with the passive and worker-side checks that remain valid, then records that active coverage was reduced. You still receive useful results instead of a fully cancelled run.
Do teams share the same findings and site inventory?
Yes. Teams and ownership shape visibility, routing, and accountability inside the same workspace. Site records, scan history, and findings remain part of the shared operational dataset.
Can I automate scans without using the UI?
Yes. The API supports site creation, scan launch, status retrieval, and downstream automation. Full API reference documentation is available separately.
Next steps
Open the app, add a real asset, and launch the first scan.
The docs cover the path. The fastest way to learn the product is to walk one real asset through verification, a Standard scan, and a findings review.