First-time setup
LogWizard has not been set up yet: there is no LogWizard administrator, so nobody can sign in. The first LogWizard administrator is created on the server itself. Only someone with access to the server can do this.
- Run the setup command on the server, from the LogWizard folder:
node scripts/bootstrap-super.js --tenant <tenant-id> --name "<Company name>" --email <your email>
The tenant id is a short lowercase name such asacme-corp. If the tenant already exists, the administrator is added to it. - Open the invite link the command prints (valid for 7 days, one use), then set your password and, if asked, your authenticator app.
- Refresh this page and sign in with your email and password.
- Add your first application as that administrator: open System Settings, choose Add application, enter the company's read-only AWS key in Step 1, then discover its log groups.
Full details: docs/login_account_process.md, "First-time setup".
Health Summary
Quick Search
Search Logs
Choose what you are searching for, or leave it on Auto-detect. A mobile number is found in every format (27…, +27…, 0…). With “Only named field” ticked, lines that merely contain the text are hidden — untick it to see them. If left blank, From/To default to the last 24 hours.
AI Insights
Ask about errors, patterns, or specific log lines for the selected application within the chosen time range. The assistant searches real log data before answering.
AI-generated from log data only -- verify before acting on it.
Q & A
What is LogWizard?
LogWizard is a tool for browsing, searching, and analyzing your application's CloudWatch logs across AWS accounts without needing direct console access -- covering health monitoring, saved/templated searches, free-text search, session path visualization, and AI-assisted log analysis.
How is the Health status calculated?
Health is based on the ratio of ERROR-level log lines to total log lines in the selected time window: Healthy at or below the app's configured error-rate threshold, Degraded up to 3× that, Unhealthy above it, or Unknown if there was no traffic in the window. See the note under the Health Summary tile for the exact numbers.
What's the difference between CloudWatch Logs, X-Ray, RUM, and LogFolder?
CloudWatch Logs
Messages the application writes about its own activity, in plain language — e.g.
"[error] : DXL request failure". The most detailed source, since it
explains things in the app's own words.
X-Ray
Tracks each step a request takes through the system (one service calling another) and
marks exactly which step succeeded or failed, and how long each one
took. Shows where something broke, not why.
RUM (Real User Monitoring)
Captures what happened on the user's own device or browser — for example,
whether a page failed to load, an error was shown, or something broke in the browser
itself.
LogFolder
Reads the same kind of log lines as CloudWatch Logs, but from a local or shared folder
instead of AWS — an offline alternative for an application whose logs aren't (or
can't be) shipped to CloudWatch. Takes priority over CloudWatch Logs when both are
enabled for an application.
Whether Cloudwatch, X-Ray, RUM, and LogFolder are enabled for the currently selected application is shown under the Health Summary tile (green = enabled, dark grey = disabled).
What are Pre-configured Searches?
Ready-made analyses -- like ranking the top errors affecting the most users, or finding the error that blocked a specific user's journey -- that would otherwise require hand-writing a CloudWatch Logs Insights query.
How does Search Logs matching work?
Search always matches any text in the raw log line (e.g. an MSISDN, session ID, or keyword), since which field holds that value varies by service. Use the journey filter and time range to narrow results.
What does the Session Path diagram show?
A visual, step-by-step path a user's session took through the application's services, in order, with counts and timestamps at each hop -- useful for spotting where a journey stalled or errored.
Can I trust the AI-generated content?
Treat it as a starting point, not a verdict. AI Insights and error-detail narratives are generated from real log data by an AI model, but can still be incomplete or wrong -- always verify against the underlying log lines before acting on them.
Why am I being asked to log in again?
Your LogWizard session ends after 30 minutes of inactivity, or 8 hours after you logged in. Log in again with your email, password and (if enabled) authenticator code, and your request will automatically retry. You never log in to AWS yourself -- LogWizard uses your company's read-only AWS key for the selected application.
Error Demo
Exercises LogWizard's generic event/error logger. Steps 1, 2, and 5 always succeed. Steps 3
(frontend) and 4 (backend) each run a small, intentionally naive demo function -- edit
runStep3DemoLogic() in public/js/errorDemo.js or
runStep4DemoLogic() in routes/errorDemo.js to introduce a different
bug and see it caught and logged the same way. Every click writes a standardised entry to
logs/error-demo-test/app-events.log (and
logs/error-demo-test/app-errors.log for errors) -- a folder kept separate from
LogWizard's own process logs, and read live by the LogFolder-backed apps.
Service Map
The selected application's live service topology from AWS X-Ray (read-only) — each box is a service and each arrow is a call between them, coloured by how many of those requests failed ( faults exceed this app's error-rate threshold, some errors/faults, healthy, no traffic in the window). Hover a box or arrow for request/error counts and average latency, or click a service to drill into its recent traces and their error detail. Nothing here is written back to AWS or to config.
User Journeys
Stitches the selected application's recent AWS X-Ray traces (read-only) into per-user journeys — every request sharing the same correlation value (a session id, MSISDN, or subscriber id, whichever the traces carry) grouped together and ordered in time, so you can follow the whole path one user took across many requests. Journeys with failures are listed first. Click a step to open that trace's full X-Ray segment detail. Nothing here is written back to AWS or to config.
System Settings
Tenant configuration
Application limits
The maximum number of applications each tenant may have. This is linked to billing and only a super user can change it. Every change is recorded in an audit log. New tenants start with a limit of 1.
| Tenant | Applications used | Limit | Last changed |
|---|
Recent changes
Tenant access
Suspending a tenant stops its users from signing in, and anyone signed in is logged out on their next action. Its applications, settings and data are kept, and Enable restores access straight away. A reason is required, and every change is recorded in an audit log.
| Tenant | Status | Last changed |
|---|
AI service
Where AI features (AI Insights, Fix Code, reports, headlines) send their requests. Tenants on Central use LogWizard's own Amazon Bedrock account, so they don't need Bedrock enabled themselves; tenants on Own account use their own AWS key. Reading logs always uses the tenant's own key. Only a super user can change this.
Central AI connection
AI source per tenant
| Tenant | AI source | Last changed |
|---|
AI usage (tokens)
For billing the central AI cost. Counted from every successful AI call; never includes prompts, answers or log text.
| Tenant | This month | Last month |
|---|
Add tenant
Onboard a new company (tenant) and its first administrator. It's added to
config/tenants.yaml only — never anything in AWS. The admin
gets a one-time invite link to set their own password.
Add application
Create a new application without editing files. It's added to
config/apps.yaml only — never anything in AWS. After it's created,
use the application-configuration steps below to enter its AWS key and discover its log groups.
Application configuration
enabled · disabled
Verify AWS Credentials & Resolve Account ID Required — do first
Confirms the selected application's AWS credentials actually work and shows which account they
authenticate as (read-only sts:GetCallerIdentity — it needs no IAM permission of
its own). If the resolved account doesn't match the accountId already in config, that's
flagged as a mismatch to fix.
Enter or update AWS access key
Enter a read-only AWS access key for this application. It's verified against AWS
(read-only sts:GetCallerIdentity), then saved encrypted on
the server (under ~/.logwizard, never in config or the browser) and
used immediately — no server restart. Stored against this app's configured
key names ().
Source code repository (GitLab)
Fix Code and Create Report search this GitLab project for the failing code. LogWizard only
reads from GitLab. Use a project access token with read_api and
read_repository scope. It's checked against GitLab, then saved
encrypted on the server and never shown again. A user who chooses a folder on
their own PC under User Settings is searched there instead.
Integrations Required
Enables or disables Cloudwatch, X-Ray, RUM, and LogsFolder as error-log sources for the
selected application in LogWizard's own config (config/apps.yaml) — this
never creates, changes, or deletes anything in AWS itself.
Discover CloudWatch Log Groups Required when Cloudwatch enabled
Lists log groups that actually exist in the selected application's AWS account/region
(read-only), to help keep config/apps.yaml's logGroups/journeys
up to date. Tick the log groups you want and Save log group changes to update
config/apps.yaml. Saving only affects the log groups currently shown here:
ticked ones are kept in config, un-ticked ones that are shown are removed, and any log groups
not shown (filtered out, or not fetched) are left unchanged — or copy the YAML and paste it
by hand. Only apps.yaml is written, never anything in AWS. The keyword filter below
only searches within whatever was already fetched, so narrow with the prefix filter first on
large accounts.
Suggested Journeys
AI-generated from log group names only — verify before
pasting into config/apps.yaml.
Discover X-Ray Services Optional
Lists the X-Ray services that appear in the selected application's service map over a recent
window (read-only), to help you set config/apps.yaml's
xray.serviceNames. This scope is optional — tick one or more services
and Save selected service scope to limit X-Ray to just those, or save none
(untick all) to search across all error/fault traces. Writes only apps.yaml, never
anything in AWS. Only services that emitted a trace within the lookback window appear, so widen
the window if a service you expect is missing.
Discover RUM App Monitors Required when RUM enabled
Lists the CloudWatch RUM app monitors that actually exist in the selected application's AWS
account/region (read-only), to help you set config/apps.yaml's
rum.appMonitorNames. At least one is mandatory whenever rum.enabled is
true — without one there is nothing for LogWizard to query, so RUM never returns
results. Tick one or more monitors and Save selected monitors to write them into
apps.yaml (never anything in AWS), or copy the YAML and set it by hand.
User Settings
Where Fix Code and Create Report look for each application's source code. By default they search the app's GitLab repository (connected by a tenant admin in System Settings). You can instead choose a folder on your own PC: it's searched here in your browser, only the matching lines are sent to LogWizard, and the choice is remembered in this browser only. Choosing a folder works in Google Chrome and Microsoft Edge only.
Manage Users
Users of your own company only -- add someone by email and pick which of your applications they can see, then copy their invite link and share it with them however you normally would (email, Teams, etc.). They use it once to set their own password.
Two-factor authentication
When on, every email & password user must set up an authenticator app before they can use LogWizard. Anyone who hasn't yet is prompted to enrol at their next login. If a user loses their device, use Reset 2FA on their row below so they can re-enrol.
Turning 2FA off does not delete anyone's 2FA setup. It simply stops being asked for, and it's asked for again at the next login once you switch it back on.