Documentation

Logs and Forwarding

Overview

The Logs page is where a tenant reviews log entries, sees how long they are kept, and records the external systems it intends to forward logs to. It has three tabs: System Logs, Log Settings, and Log Forwarding.

Two things to know before you rely on it:

  • Log forwarding delivery is not available in this release. You can create, edit, and delete forwarding destinations, but Veltrix does not yet send log entries to them. See Log Forwarding.
  • The Logs page is not the audit trail. Who-did-what history (sign-ins, configuration changes, deployments) is shown on the Audit Logs report. See Reports and Audit.

Where to Find It

Open Settings → Logs in the sidebar (route /settings/logs). The path /logs redirects to the same page. The page title is "Logs Management" and each tab is selected in-page; the selected tab is not stored in the URL.

TabWhat it does
System LogsBrowse and filter your tenant's log entries.
Log SettingsShows your plan's log retention period (read-only).
Log ForwardingCreate, edit, and delete forwarding destinations.

Every log entry and destination belongs to one tenant; you only ever see your own.

System Logs

The System Logs tab lists log entries newest first, 25 per page, with server-side pagination.

Filters

FilterBehavior
LevelAll levels, Debug, Info, Warning, or Error.
SourceFree-text field. The match is exact: the entry's source must equal what you type (leading and trailing spaces are trimmed).
From / ToDate pickers. Entries with a timestamp on or after From and on or before To are returned. A date is read as the start of that day, so to include all of the last day, pick the following day as To.
RefreshRe-runs the current query on the current page.

Changing any filter returns you to page 1. If nothing matches, the table shows "No log entries" and suggests adjusting your filters.

Columns

ColumnContent
TimeThe entry timestamp in your browser's locale.
LevelA badge: DEBUG, INFO, WARN, or ERROR.
SourceThe component or system that wrote the entry.
MessageThe log message.

Where entries come from

Entries on this tab are tenant log entries written through the API (POST /api/logs with a level, a source, a message, and an optional details string). The portal does not provide a form for writing entries, and a log entry's details string is stored but not displayed in the table. The Veltrix server's own diagnostic output is a separate, operator-level log; see Server diagnostic log.

Deleting an entry (DELETE /api/logs/:id) is available through the API only. The API also exposes GET /api/logs/sources and GET /api/logs/levels (the distinct sources and levels in your tenant), and GET /api/logs/:id. Page size is capped at 100 per request on the API.

Log Settings

The Log Settings tab shows a single read-only card titled "Log retention": how long log entries are kept before they are purged, in days, based on your plan. There is nothing on this tab to configure. If your plan has no retention limit the card reads "Unlimited"; if the value cannot be loaded, an error is shown in place of the number.

Retention by Plan

Retention is a plan feature. A nightly job (02:30 server time by default) deletes tenant records older than your plan's window from four tables: log entries, audit events, configuration history, and deployment logs. The same window therefore governs both this page and the Audit Logs report.

PlanRetention window
Free7 days
Starter30 days
Professional90 days
Enterprise365 days
  • The free-tier purge is controlled by a platform-level switch that is off by default. Until a platform operator turns it on, the job skips free tenants and their history is not purged, even though the card shows 7 days. Do not treat the free-tier figure as a guarantee in either direction.
  • A platform operator can override the window for an individual tenant. The Log Settings card shows the plan value.
  • Purging is permanent. If you need records longer than your window, export them first (the Audit Logs report supports CSV and Excel export).

Plan limits are described by feature here; see Plans and Trial for the plan overview.

Log Forwarding

Delivery is not implemented in this release. Creating a destination records the configuration only. Veltrix does not send logs to your Splunk, Elasticsearch, Datadog, Sumo Logic, or custom endpoint, and the server's connection-test endpoint answers "not implemented" instead of reporting a success it cannot substantiate. Do not rely on this tab as a SIEM feed or as compliance evidence that logs are being forwarded.

The Log Forwarding tab lists your saved destinations and lets you maintain them so the configuration is ready when delivery ships. The tab shows a "Configuration only - delivery not yet available" notice above the list, and the Settings card for Logs says the same.

Add a destination

  1. Open Settings → Logs → Log Forwarding and select Add destination (also offered from the empty state).
  2. Enter a Name (required, for example "Production Splunk"). Names are unique within your tenant.
  3. Choose a Destination type: Splunk, Elasticsearch, Datadog, Sumo Logic, or Custom (HTTP endpoint).
  4. Enter the Endpoint URL. It is required, must be a valid URL, and must use https://; anything else is rejected before saving.
  5. Select Add destination. A new destination starts with the status inactive.

The destinations table

ColumnContent
NameThe destination name.
Typesplunk, elasticsearch, datadog, sumologic, or custom.
EndpointThe saved HTTPS URL.
StatusA badge: active, inactive, or error.

Each row has Edit (same form as Add; changes name, type, and endpoint) and Delete (asks for confirmation). There is intentionally no "Test connection" button. The status value is stored with the destination, but because nothing is delivered it does not reflect the health of a real connection. The Delete confirmation states that logs are not being delivered to the destination today, so deleting only removes the saved configuration.

The API also accepts a status on update (PUT /api/log-forwarding/:id). Setting a status manually does not start delivery.

What is not available: field-level mapping, filters by level or source, authentication headers or tokens for the endpoint, batching or retry settings, and a delivery history. None of these exist in the code today.

Permissions

CapabilityPermission
View System LogslogEntry:read
Write or delete log entries (API)logEntry:write
View forwarding destinationslogForwarding:read
Add, edit, delete destinationslogForwarding:write

The built-in Administrator role holds every permission. Custom roles are managed under Access Control; see Access Control. Log Settings reads your plan's retention from the subscription and has no separate permission of its own. Log endpoints are tenant-scoped and use portal sign-in (JWT); they do not accept API keys.

Server Diagnostic Log

This section is for operators who run their own Veltrix server (see Installation Options). It is separate from the tenant-facing tabs above.

  • Level: set with LOG_LEVEL. When unset the default is warn in production, info in staging, and more verbose in development. LOG_FORMAT selects the output format (JSON in production and staging).
  • Log files: outside development the server also writes an asynchronous, size-rotated log file. LOG_FILE_PATH (default /var/log/veltrix/app.log), LOG_FILE_MAX_SIZE (default 100 MB) and LOG_FILE_MAX_FILES (default 30) bound its footprint.
  • Redaction: values under keys such as password, secret, token, API key, authorization, cookie, credential, private key, and connection strings are replaced with [REDACTED] at any nesting depth before a line is written.

Gotchas

  • Forwarding is configuration only; nothing is delivered. This is the most important limitation on this page.
  • An empty System Logs tab is normal for a tenant that does not write entries through the API.
  • The Source filter is an exact match, not a "contains" search.
  • The To date is read as the start of that day.
  • Retention applies to log entries, audit events, configuration history, and deployment logs together; shortening or lengthening your plan changes what the Audit Logs report can show.
  • Endpoints must be https://; plain http:// URLs are rejected.
  • Destination names must be unique within a tenant.