xlnszia Docs App

Usage Guide

This guide explains how to use the application. Sign in at https://app.xlnszia.com with your email and password.

Dashboard

The dashboard gives you an overview of everything at a glance:

  • Total tests and their status breakdown (valid / warning / critical / expired / unreachable / ok / failed).
  • Failing tests that need attention.
  • Recent alerts and the last 14 days of check history.
  • Breakdown by environment (Production, Acceptance, Developer, Sandbox, Proof of Concept).

Tests

Tests are the monitors you create. Two types are available:

TypeWhat it checksStatuses
SSL / TLS ExpiryCertificate expiry, warning/critical thresholds, issuer, days leftvalid, warning, critical, expired, invalid, unreachable
DNS ResolutionResolves the domain (A / AAAA), reports addresses + response time; optional expected-address comparisonok, failed, mismatch, timeout

When creating a test you can set:

  • Target — the hostname to monitor.
  • Check interval — how often it runs (the background checker picks due tests every 60s).
  • Warning / critical thresholds — for SSL, the number of days before expiry to warn.
  • Team — who can see and manage the test.
  • Environment — which deployment environment it belongs to.
  • Active — enable/disable without deleting.

You can trigger a manual check any time from the test page, and every run is stored in the check history.

Alerts & notifications

Alert rules decide when you get notified. Each rule has:

  • A test it watches.
  • A title and message (placeholders: {name}, {target}, {status}, {days_left}, {error}).
  • A condition — any_failure or a specific status.
  • A severity (info / warning / critical).

When a rule's condition matches a check result, an alert is created. Fired alerts can be acknowledged, resolved or reopened. When a test recovers, matching alerts are auto-resolved.

Integrations

Alerts can be pushed to external systems. Supported integrations:

  • Email (SMTP) — send alert emails to one or more recipients.
  • Datadog — logs and metrics.
  • OpenTelemetry — OTLP/HTTP log export.
  • MySQL / PostgreSQL / MariaDB / MongoDB — store alerts in a database table/collection.

Passwords and API keys used by integrations live in the Key Vault (encrypted with Fernet) and are referenced from the integration form — never store them in plain text.

Teams, users & roles

  • Teams group users; tests can be assigned to a team and access is scoped by team.
  • Users are created by admins (email + password).
  • Roles control permissions per resource: dashboard, tests, alert rules, alerts, users, teams, environments, roles, events, audit, tokens, integrations, secrets, governance, SSO.
  • System roles: Admin, Manager, Viewer — and custom roles can be created.

Environments

Deployment environments (Production, Acceptance, Developer, Sandbox, Proof of Concept) let you organise tests by where they run. Dashboards can be filtered by environment and the tests list can be filtered too.

Governance & plans

The workspace has a plan (Free / Pro / Enterprise) with limits on tests, users, teams, tokens, integrations, secrets, rules and daily checks/alerts/events. Current usage is shown under Settings → Governance.

Events & audit

  • Events — a live stream of every check and whether it triggered an alert (filters: type, severity, alert triggered, test).
  • Audit trail — time, user, action and description for every meaningful action.

Personal access tokens

Create tokens under Settings → Governance → API Tokens (name, expiry, scope permissions) and use them with Authorization: Bearer <token> — see Authentication.