Privacy Policy

Version not yet assigned · scope: public paid beta

Draft — not published for production use

Publication is blocked by: Operator legal name supplied; Service / business address supplied; Country supplied; Governing law supplied; Policy version assigned; Policy effective date set and not in the future; Public exposure switch is ON; Operator profile file found; Deployed build identified (image digest / build info).

These pages are a non-public review draft. They are not part of the paid beta and are not advertised as complete legal documents.

Missing operator details: Operator legal name, Service / business address, Country, Governing law. The operator identity is a real, verifiable fact and is never replaced by the brand name.

Who operates the service

Service (trading name): Qalizer
Legal operator: Not yet supplied — Qalizer is a product brand, not a legal entity.
Service address: Not yet supplied
Country: Not yet supplied
Registration / tax: Not applicable / not supplied
Contact: support@qalizer.online (support, privacy and legal requests share this one inbox)
Policy version: Not yet assigned · no effective date set

Qalizer is an automated quality-assurance service for web applications. This policy describes which data the service processes, why, where it is processed, how long it is kept, and which rights you have. Content marked not yet supplied is a real gap the operator must fill before publication — it is never replaced by an assumption.

1. What data we process

Account data: email address, hashed password, display name, time zone, optional 2FA secret, account type and an optional company name used only as display data — never for authorization.
Workspace data: workspace display names, membership rows (role, status, who approved the join request) and single-use, expiring invitations stored only as a hash.
Monitor configuration: target URLs, monitor names, crawl/testing settings, schedules and the feature switches you enable.
Test assets: recorded or AI-generated scenarios, requirements you upload, API-test definitions and data-injection rows.
Execution artifacts: run results, per-step results, screenshots, screen recordings (when you enable recording), console/network captures, and generated HTML/PDF/JSON/JUnit exports.
Operational logs: monitor activity entries (who did what, how many credits it cost), admin broadcast log, authentication/2FA audit events and application log files.
Credits and billing metadata: credit balance, credit transactions, purchase records and the identifiers Stripe returns for a payment. Card data is handled by Stripe and never reaches Qalizer.
Support requests: the contact-form content, the references you provide and any evidence files you choose to attach.

A session cookie keeps you signed in and the theme preference is stored locally in your browser. No advertising or third-party analytics tracker is used.

2. Why we process it (purposes and legal bases)

Providing the service (account, monitors, execution, reports, CI) — performance of the contract.
Credits, purchase records and tax/accounting obligations — performance of the contract and legal obligation.
Security, abuse prevention and audit (auth events, activity log, runner jobs) — legitimate interest in keeping the service available and safe.
Answering support, privacy and legal requests — legitimate interest and legal obligation.
AI-assisted features you switch on — performance of the contract for that feature (see §4).

We do not use your test data to train AI models.

3. Where it is processed

The application, database, runner pool, reports and backups of this deployment run on a cloud instance in Germany. That describes the server location: it does not mean that every processor is in Germany, because the providers in §5 process data in their own locations. Data leaves the EU only for the providers listed there, and that list is kept in step with the deployed configuration.

Your website is contacted from wherever the execution actually runs:

Shared server pool — a runner on the German server.
Your local runner — your own machine, which then sees your network location.

The product shows which of the two applies, and every run records where it executed.

4. AI processing

AI features cover crawl assistance, scenario generation, requirements analysis, selector healing, report verification and failure summaries. Each feature builds its payload from the data it needs:

Crawling, scenario generation, test generation, requirements analysis, selector healing: page structure and text (elements, labels, selectors, navigation targets), the requirement text you upload, and the steps/selectors that failed.
AI report verification and failure analysis: scenario steps, step results, the report summary and a limited number of screenshots (count and size capped, duplicates removed).
Bug-summary generation: the failed step and its error text.

Provider keys stay in the backend, and job payloads dispatched to a runner are allow-listed, so credentials, cookies, headers and free-form code are not forwarded. We do not claim that a password, token or secret can never appear inside a screenshot or in page text that you ask us to analyse — a page or screenshot is captured as it is. Do not test pages that display secrets you are unwilling to expose to a model; the AI features are optional and can stay switched off.

Configured providers and fallback order for this deployment (only providers with an active API key are contacted):

Groq (US) — crawl, scan/prepass, scenario generation, test generation, selector healing, gate forms, analysis, ad-hoc tasks, bug summaries.
DeepSeek (outside the EU) — crawl, scan/prepass, scenario generation, requirements analysis, test generation, selector healing, gate forms, analysis, ad-hoc tasks, bug summaries, report verification.
Google Gemini (US) — crawl, scan/prepass, scenario generation, requirements analysis, test generation, selector healing, gate forms, analysis, ad-hoc tasks, AI report verification.

If a provider is unavailable, throttled or not configured, the next provider in that task's chain is tried. The order is groq → deepseek → gemini, except for requirements analysis (starts with deepseek) and analysis (starts with Gemini). A provider is only a processor here when an operator has configured its API key for this deployment; integrations that exist in the code but have no active key for this deployment are not listed, and this page does not claim to know the operator's live configuration — the operator preview (admin-only) reports which keys are configured.

5. Service providers

Cloud hosting (OCI, Germany) — application, PostgreSQL database, runner pool, reports and backups.
Purelymail — mailbox and SMTP sending for transactional email. Mail addressed to support@qalizer.online arrives at Purelymail and is forwarded to the operator's Gmail inbox, where support, privacy and legal requests are read and answered.
Google Gmail — receives the forwarded support mail and is used to reply to it.
Stripe — card payment processing and receipts. Card data is entered on Stripe's checkout and is never stored by Qalizer.
AI providers — listed in §4.
Docker Hub — distributes the public local-runner container image; it receives no customer data.

We do not sell personal data. It is shared only to run the service, to comply with the law or on your instruction.

6. Authorization: who can see your data

Your personal resources (monitors, scenarios, runs, reports, recordings, CI tokens) are visible to you, the owner.
A workspace grants access only through an approved, active membership. Pending or rejected join requests and removed memberships grant no access at all, and an identical workspace name grants nothing.
Sharing is explicit per monitor. Membership changes apply on the next request — an open session, CI token or live stream loses access immediately.
"Not publicly accessible" means no other customer can reach your data. It does not mean that nobody else ever processes it: the operator runs the infrastructure and is a cloud, email and AI provider customer, so those parties process data as described in §4 and §5.

7. How long we keep data

Only the retention periods that are enforced and approved are promised here:

Completed execution artifacts — reports, per-step results, embedded screenshots, recordings, console/network captures, generated exports and persistent/combined report copies — are removed 180 days after the execution finished.
Operational logs — application log files, monitor activity log, authentication/2FA audit events and the admin broadcast log — are kept 250 days.
Reusable configuration (monitors, scenarios, requirements, schedules) is not deleted when a report expires.
Monitors in trash are permanently removed after 7 days.
Financial and credit records follow a separate legal/accounting schedule; the artifact retention above never shortens them.

Deliberately not promised, because no expiry is enforced for them yet: support-request retention, backup retention and runner/container log rotation. Where those categories exist they are kept until the operator removes them under the applicable schedule.

Where a run was paid for, the financial reference is kept and only the artifact payload is removed, so deletion never destroys the record needed to settle a charge.

Expiry is visible in the product: the Profile area reports the retention policy and your current storage use, and every report shows the retention that applies to it. The policy numbers above are the configured values; whether expiry is currently running for this deployment is reported by the operator preview (admin-only), and the product reports the last completed expiry pass rather than assuming one has run.

8. Cookies and local storage

Only a session cookie (required to stay signed in) and a locally stored theme preference are used. There is no advertising, cross-site or analytics tracking.

AI output is advisory. Execution results produced by the runner remain authoritative.

9. Your rights

You can request access, rectification, erasure, restriction and portability, and you can object to processing based on legitimate interest. Write to support@qalizer.online or use the contact form; requests are answered within the statutory period. You also have the right to complain to the data-protection supervisory authority of the operator's country (authority not yet supplied).

10. Account deletion

You can delete your account and monitors in the product. Deletion removes access and the associated artifacts, except records the operator must keep for tax, accounting, fraud-prevention or legal-defence reasons, and the copies held in backups until those rotate out. Which records those are follows the retention and financial schedules in §7.

11. Security

Traffic is encrypted in transit (TLS), passwords are salted and hashed, 2FA is available, and access to monitors and reports is re-checked on every request. No internet service can promise absolute security; protect your credentials and any evidence file you upload (never attach passwords, API keys or third-party personal data).

12. Changes

The version and effective date at the top of this page identify the text in force. A change is published with a new version and an effective date, and signed-in users are told about material changes.

13. Contact

Privacy questions: support@qalizer.online — the same inbox used for support and legal requests. The responsible operator is identified at the top of this page.