Detailed operational guide for every
current dashboard category. Only one
category is shown at a time, with
procedures, diagrams and realistic
result examples.
Running version:
1.25
Select a category or search
the complete guide.
Category
1
of
8
Getting started and navigation
Understand the dashboard structure, the left sidebar, the top header, themes, sessions and the recommended workflow.
1
Step-by-step procedure
Sign in with your Security Analyzer account.
Confirm your name or email in the top header.
Use the left sidebar to open a product category.
Expand only the category you are currently using.
Use the top Help and FAQ buttons whenever you are blocked.
Start with New scan or Configure uptime.
Return to the Dashboard to review the recommended next action.
How to read the page
The top header identifies the current page and connected account.
The sidebar version indicates the running Analyzer release.
The blue highlight identifies the active page.
Collapsed sidebar icons display tooltips on hover.
The dark and light buttons change only the current browser display.
Mini workflow diagram
Simplified sequence for
this module.
1Sign in
→
2Dashboard
→
3Choose module
→
4Follow next action
Example of expected results
◎
Example: a correctly identified session
Area
Example result
Meaning
Header identity
Guillaume Oneill · user@example.com
The authenticated user is clearly visible.
Sidebar
Operations cockpit · v1.25
The running Analyzer version is visible.
Next best action
Configure uptime
The dashboard proposes the next useful step.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Never share your dashboard session, status-page token, license key, alert webhook or private report URL.
Getting started and navigation
Category
2
of
8
Security scans
Launch an authorized scan, follow its execution and understand Runs, Summary, Targets, Findings, Risk Matrix and Compare.
2
Step-by-step procedure
Open New scan.
Enter a complete HTTP or HTTPS target URL.
Choose quick for a baseline, standard for normal use or deep for a longer audit.
Confirm that you own the target or are explicitly authorized.
Open Scan jobs and follow the live execution log.
Wait for completed or investigate failed jobs.
Open the generated run and review the executive summary first.
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.
Mini workflow diagram
Simplified sequence for
this module.
1Authorized target
→
2Scan profile
→
3Live job
→
4Stored run
→
5Summary
Example of expected results
◎
Example: security scan summary
Indicator
Example result
Interpretation
Decision
CONDITIONAL GO
High-priority issues still require action.
Score
68 / 100
The target needs hardening.
Coverage
14 tools · 1 timeout
Review the missing coverage before trusting the score.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Never scan a third-party target without permission. A GO decision is an automated baseline, not an absolute security guarantee.
Security scans
Category
3
of
8
Findings and remediation workflow
Triage security findings, document decisions, apply fixes and verify the result with a new scan.
3
Step-by-step procedure
Filter Findings by severity, tool, target or text.
Start with critical and high items.
Read the evidence before changing the lifecycle status.
Mark Fixed only after a technical correction exists.
Use Retest needed when the correction must be verified.
Use Accepted risk only for a documented business decision.
Use False positive only after technical validation.
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.
Mini workflow diagram
Simplified sequence for
this module.
1Finding
→
2Triage
→
3Apply fix
→
4Retest
→
5Close or accept
Example of expected results
◎
Example: finding lifecycle result
Field
Example result
Interpretation
Severity
HIGH
Fast correction or formal risk acceptance is required.
Lifecycle
Retest needed
A new scan must validate the correction.
Tool
testssl
The evidence comes from the TLS analysis.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Do not improve statistics by hiding findings. Lifecycle states must represent real technical or business decisions.
Findings and remediation workflow
Category
4
of
8
Uptime monitoring
Configure monitored websites, choose the frequency, collect probes and interpret availability percentages and response times.
4
Step-by-step procedure
Open Configure uptime.
Add a clear website name and complete URL.
Set the expected HTTP status only when 200 is not the normal response.
Choose a reasonable check frequency.
Enable or disable monitoring.
Choose whether the target is published on the public Status Page.
Configure email or advanced notification webhooks.
Run Test now and then Test alert.
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.
Mini workflow diagram
Simplified sequence for
this module.
1Monitored target
→
2Central scheduler
→
3HTTP probe
→
4Availability metrics
→
5Alert
Example of expected results
◎
Example: uptime result
Indicator
Example result
Interpretation
Latest status
online
The most recent probe succeeded.
24-hour uptime
99.96%
Availability calculated from stored probes.
Response time
184 ms
Observed duration of the latest HTTP response.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Do not configure an aggressive frequency for a non-critical service. Keep Slack, SMS and WhatsApp webhook URLs private.
Uptime monitoring
Category
5
of
8
Incidents and public Status Page
Understand automatic outage incidents and safely publish a read-only service status page.
5
Step-by-step procedure
Open Incidents and review open incidents first.
Open the incident detail and inspect recent probes.
Resolve manually only when correcting an exceptional state.
Mark test incidents so they do not pollute production statistics.
Open Status page from the Uptime category.
Choose Private or Public publication.
Select published or hidden for each uptime target.
Open the tokenized public URL in a private browser window.
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.
Mini workflow diagram
Simplified sequence for
this module.
1Failed probe
→
2Open incident
→
3Recovery probe
→
4Resolved incident
→
5Public status
Example of expected results
◎
Example: incident and Status Page result
Indicator
Example result
Interpretation
Global status
Degraded
A warning, missing probe or partial issue exists.
Incident
Open · 12m 04s
The outage is still unresolved.
Public URL
/status/<token>
Read-only page accessible with its private token.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
The public token is an access credential. Anyone who receives it can open the published status page.
Incidents and public Status Page
Category
6
of
8
Site Intelligence
Review non-intrusive DNS, HTTP, SEO, indexability and public performance information.
6
Step-by-step procedure
Open Site intelligence.
Choose a stored intelligence run.
Review the global decision and score.
Read findings by severity.
Inspect tool results and raw evidence.
Review DNS, HTTP, SEO and performance metrics.
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.
Mini workflow diagram
Simplified sequence for
this module.
1DNS
→
2HTTP
→
3SEO
→
4Performance
→
5Intel report
Example of expected results
◎
Example: Site Intelligence result
Domain
Example result
Interpretation
DNS
OK
The public DNS baseline passed.
SEO
ACTION REQUIRED
A visibility issue exists; it is not automatically a vulnerability.
Performance
82 / 100
The public performance baseline is good but improvable.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Do not classify every SEO or visibility warning as a security vulnerability.
Site Intelligence
Category
7
of
8
Owner administration
Use Scheduler, Health, Log and Cleanup only for platform operations.
7
Step-by-step procedure
Open Scheduler and confirm a recent heartbeat.
Review active users and scheduler targets.
Filter scheduler events and investigate errors.
Pause the scheduler only for controlled maintenance.
Use Health to verify database and runtime status.
Use Log for recent dashboard events.
Create a backup before using Cleanup.
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.
Mini workflow diagram
Simplified sequence for
this module.
1Scheduler daemon
→
2Users
→
3Targets
→
4Health and logs
Example of expected results
◎
Example: scheduler health result
Indicator
Example result
Interpretation
Daemon
running
The heartbeat is recent.
Active users
4
One central daemon serves several users.
Last probes
18
Targets checked during the latest scheduler tick.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Administration pages are owner-only. Cleanup must never be used as a normal maintenance shortcut.
Owner administration
Category
8
of
8
Account, session and troubleshooting
Identify the connected user, close the session safely and collect useful information before reporting a problem.
8
Step-by-step procedure
Check the connected identity in the top header.
Use the top Logout button or the sidebar Logout entry.
Sign in again if the session expired.
Refresh the page once after a service restart.
Check Health and Log when you are the owner.
Record the exact page, action, time and visible error.
Keep the Analyzer version number with the support request.
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.
Mini workflow diagram
Simplified sequence for
this module.
1User action
→
2Visible error
→
3Health and logs
→
4Sanitize data
→
5Support request
Example of expected results
◎
Example: troubleshooting result
Signal
Example result
Interpretation
HTTP 403
Forbidden
The connected account lacks owner permission.
HTTP 503
SQLite busy
Retry after the active database write finishes.
Support context
v1.25 · page · time · sanitized log
Enough information to investigate without exposing secrets.
Demonstration data only. Actual values
depend on the selected target and
collected history.
Important:
Support information should contain logs and timestamps, but never secrets or personal credentials.
Account, session and troubleshooting
Still blocked?
Open the FAQ, then collect the exact
page, action, timestamp and sanitized
log message.