Security Analyzer Online Help

Step-by-step procedure

1. Open New scan.
2. Enter a complete HTTP or HTTPS target URL.
3. Choose quick for a baseline, standard for normal use or deep for a longer audit.
4. Confirm that you own the target or are explicitly authorized.
5. Open Scan jobs and follow the live execution log.
6. Wait for completed or investigate failed jobs.
7. Open the generated run and review the executive summary first.
8. Inspect skipped and timed-out tools before trusting the score.

How to read the page

• Runs stores the chronological scan history.
• Summary translates technical results into decisions and priorities.
• Targets groups the scan history by website.
• Findings contains technical evidence and remediation advice.
• Risk Matrix ranks operational exposure.
• Compare identifies new, fixed and unchanged findings.

Step-by-step procedure

1. Filter Findings by severity, tool, target or text.
2. Start with critical and high items.
3. Read the evidence before changing the lifecycle status.
4. Mark Fixed only after a technical correction exists.
5. Use Retest needed when the correction must be verified.
6. Use Accepted risk only for a documented business decision.
7. Use False positive only after technical validation.
8. Launch a new scan and compare it with the previous run.

How to read the page

• Open means no final decision has been recorded.
• Retest needed is the verification queue.
• Fixed means the issue was corrected.
• Accepted risk remains a known exception.
• False positive means the finding does not apply.

Step-by-step procedure

1. Open Configure uptime.
2. Add a clear website name and complete URL.
3. Set the expected HTTP status only when 200 is not the normal response.
4. Choose a reasonable check frequency.
5. Enable or disable monitoring.
6. Choose whether the target is published on the public Status Page.
7. Configure email or advanced notification webhooks.
8. Run Test now and then Test alert.
9. Open Availability to review 24-hour, 7-day and 30-day statistics.

How to read the page

• A probe is one availability measurement.
• No probe means the scheduler has not collected data yet.
• Response time is the observed HTTP response duration.
• Percentages depend on the number of stored probes in the selected window.
• Disabled targets are not scheduled and are never publicly published.

Step-by-step procedure

1. Open Incidents and review open incidents first.
2. Open the incident detail and inspect recent probes.
3. Resolve manually only when correcting an exceptional state.
4. Mark test incidents so they do not pollute production statistics.
5. Open Status page from the Uptime category.
6. Choose Private or Public publication.
7. Select published or hidden for each uptime target.
8. Open the tokenized public URL in a private browser window.
9. Never publish a target that must remain confidential.

How to read the page

• One outage should create one open incident.
• Recovery normally resolves the incident automatically.
• Duration measures downtime between opening and resolution.
• Operational means all published targets are healthy.
• Degraded means warning data or missing probes exist.
• Outage means at least one published target is down.

Step-by-step procedure

1. Open Site intelligence.
2. Choose a stored intelligence run.
3. Review the global decision and score.
4. Read findings by severity.
5. Inspect tool results and raw evidence.
6. Review DNS, HTTP, SEO and performance metrics.
7. Use Site Intelligence together with security scans and uptime monitoring.

How to read the page

• DNS findings describe domain and mail hygiene.
• HTTP findings describe public protocol behavior.
• SEO findings affect discoverability and content quality.
• Performance metrics describe public response behavior.
• Site Intelligence is not a vulnerability scan.

Step-by-step procedure

1. Open Scheduler and confirm a recent heartbeat.
2. Review active users and scheduler targets.
3. Filter scheduler events and investigate errors.
4. Pause the scheduler only for controlled maintenance.
5. Use Health to verify database and runtime status.
6. Use Log for recent dashboard events.
7. Create a backup before using Cleanup.
8. Resume the scheduler after maintenance.

How to read the page

• Running with a recent heartbeat means the central daemon is alive.
• Paused means ticks are intentionally skipped.
• Late or dead heartbeat requires owner investigation.
• One scheduler handles every user and target.
• Cleanup deletes SQL scan history and must be treated as destructive.

Step-by-step procedure

1. Check the connected identity in the top header.
2. Use the top Logout button or the sidebar Logout entry.
3. Sign in again if the session expired.
4. Refresh the page once after a service restart.
5. Check Health and Log when you are the owner.
6. Record the exact page, action, time and visible error.
7. Keep the Analyzer version number with the support request.
8. Never send passwords, session cookies, license keys or webhook URLs.

How to read the page

• The session is stored in a secure browser cookie.
• Logout invalidates the active dashboard session.
• A 403 page means the current account lacks permission.
• A 404 page means the route or resource was not found.
• A 503 SQLite busy message is often temporary while a writer is active.