Vix.cpp v2.6.0 is here Read the blog
Vix.cpp/Docs
Vix.cpp

Appearance

vix logs ​

vix logs shows production logs for a Vix application.

Use it when you want to inspect systemd app logs, Nginx proxy logs, error logs, repeated failures, or live production output.

bash
vix logs
1

Overview ​

vix logs is the production log inspection command for Vix.

It can show:

  • systemd app logs
  • Nginx access logs
  • Nginx error logs
  • app errors
  • proxy errors
  • repeated error groups
  • common network disconnect groups
  • live logs
  • logs since a specific time
  • the last N lines
  • JSON output for repeated error analysis

It is useful when:

  • the app fails to start
  • health checks fail
  • public traffic does not work
  • Nginx proxy behaves incorrectly
  • WebSocket clients disconnect
  • production logs are too noisy
  • deployment failed and you need recent errors

Platform support ​

vix logs is currently supported on:

txt
Linux
1

It uses Linux production tools such as:

txt
journalctl
tail
grep
sudo
1
2
3
4

On unsupported platforms, Vix reports that vix logs is currently supported on Linux only.

Usage ​

bash
vix logs [target] [options]
1

Targets ​

TargetPurpose
no targetShow app logs and proxy logs.
appShow systemd app logs.
proxyShow Nginx access and error logs.
errorsShow app errors and Nginx error logs.

Basic examples ​

bash
# Show app and proxy logs
vix logs

# Show only app logs
vix logs app

# Show only proxy logs
vix logs proxy

# Show app errors and proxy error logs
vix logs errors

# Follow logs live
vix logs --follow

# Alias for --follow
vix logs -f

# Show only common error lines
vix logs --errors

# Analyze repeated errors
vix logs errors --repeated

# Analyze repeated errors as JSON
vix logs errors --repeated --json

# Show logs since a systemd time expression
vix logs --since "1 hour ago"

# Show last 200 lines
vix logs -n 200

# Same as -n
vix logs --lines 200
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Configuration source ​

vix logs reads configuration from:

txt
vix.json
1

under:

txt
production.logs
1

It can also reuse service names from:

txt
production.deploy.service
production.service.name
1
2

Full config example ​

json
{
  "name": "PulseGrid",
  "production": {
    "service": {
      "name": "pulsegrid"
    },
    "deploy": {
      "service": "pulsegrid"
    },
    "logs": {
      "service": "pulsegrid",
      "nginx_access": "/var/log/nginx/pulsegrid.access.log",
      "nginx_error": "/var/log/nginx/pulsegrid.error.log",
      "lines": 120
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Logs config fields ​

FieldPurpose
production.logs.servicesystemd service name used for app logs.
production.logs.nginx_accessNginx access log path.
production.logs.nginx_errorNginx error log path.
production.logs.linesDefault number of lines to show.

Service name detection ​

Vix resolves the service name in this order:

txt
production.logs.service
production.deploy.service
production.service.name
project name
1
2
3
4

If the service name ends with:

txt
.service
1

Vix normalizes it internally and uses the service name for journalctl.

Example:

json
{
  "production": {
    "logs": {
      "service": "pulsegrid.service"
    }
  }
}
1
2
3
4
5
6
7

is treated as:

txt
pulsegrid
1

Default log paths ​

If no custom Nginx log paths are configured, Vix uses default paths based on the app name.

For an app named:

txt
PulseGrid
1

the default paths are:

txt
/var/log/nginx/PulseGrid.access.log
/var/log/nginx/PulseGrid.error.log
1
2

You can override them:

json
{
  "production": {
    "logs": {
      "nginx_access": "/var/log/nginx/pulsegrid.access.log",
      "nginx_error": "/var/log/nginx/pulsegrid.error.log"
    }
  }
}
1
2
3
4
5
6
7
8

Show all logs ​

Run:

bash
vix logs
1

This shows:

txt
app logs
proxy access logs
proxy error logs
1
2
3

It prints a summary first:

txt
Logs
App: PulseGrid
Target: all
Service: pulsegrid
Nginx access: /var/log/nginx/pulsegrid.access.log
Nginx error: /var/log/nginx/pulsegrid.error.log
Lines: 120
Follow: no
Errors only: no
1
2
3
4
5
6
7
8
9

Then it runs the needed system commands.

Show app logs ​

Run:

bash
vix logs app
1

This uses:

bash
journalctl -u <service> -n <lines> --no-pager
1

Example:

bash
journalctl -u pulsegrid -n 120 --no-pager
1

Use this when the app:

  • fails to start
  • exits unexpectedly
  • crashes
  • logs runtime errors
  • cannot bind a port
  • cannot open a file
  • cannot connect to a database

Show proxy logs ​

Run:

bash
vix logs proxy
1

This shows:

txt
Nginx access log
Nginx error log
1
2

It uses commands shaped like:

bash
sudo tail -n 120 /var/log/nginx/pulsegrid.access.log
sudo tail -n 120 /var/log/nginx/pulsegrid.error.log
1
2

Use this when:

  • public traffic does not reach the app
  • Nginx returns 502 or 504
  • TLS works but upstream fails
  • WebSocket proxying fails
  • proxy headers or upstream ports are wrong

Show error logs ​

Run:

bash
vix logs errors
1

This shows:

txt
filtered app errors
Nginx error log
1
2

It filters app logs using common error keywords such as:

txt
error
failed
failure
exception
panic
fatal
critical
timeout
refused
denied
1
2
3
4
5
6
7
8
9
10

Use this when you want to focus on failures instead of normal traffic.

Error filtering ​

You can filter logs by common error keywords with:

bash
vix logs --errors
1

This applies to app logs and proxy logs where supported.

Example:

bash
vix logs app --errors
vix logs proxy --errors
vix logs --errors
1
2
3

The filter looks for common failure words such as:

txt
error
failed
failure
exception
panic
fatal
critical
timeout
refused
denied
1
2
3
4
5
6
7
8
9
10

Follow logs live ​

Use --follow or -f:

bash
vix logs --follow
vix logs -f
vix logs app -f
vix logs proxy -f
1
2
3
4

For app logs, this maps to:

bash
journalctl -u <service> -f
1

For proxy logs, this maps to:

bash
sudo tail -f <log-file>
1

Use follow mode when you want to watch logs while:

  • restarting a service
  • testing a route
  • hitting the public URL
  • connecting a WebSocket client
  • running a deployment

Show logs since a time ​

Use --since:

bash
vix logs --since "1 hour ago"
vix logs app --since "today"
vix logs errors --since "10 minutes ago"
1
2
3

--since is passed to journalctl for app logs.

Examples of valid systemd time expressions:

txt
1 hour ago
10 minutes ago
today
yesterday
2026-05-28 10:00:00
1
2
3
4
5

Show last N lines ​

Use --lines or -n:

bash
vix logs --lines 200
vix logs -n 200
vix logs app -n 50
vix logs proxy -n 300
1
2
3
4

If not configured, the default is usually:

txt
120
1

You can also set the default in vix.json:

json
{
  "production": {
    "logs": {
      "lines": 200
    }
  }
}
1
2
3
4
5
6
7

Repeated error analysis ​

Use --repeated to analyze repeated failures:

bash
vix logs errors --repeated
1

This reads app and proxy error-like lines, normalizes them, groups repeated messages, and reports common patterns.

Example output shape:

txt
Repeated Errors
Analyzed lines: 120
Repeated groups: 2
12x upstream timed out
5x connection refused

Common Network Disconnects
Detected groups: 3
Hidden normal noise: 18 lines
14x client disconnected
3x connection reset by peer
1x timeout
1
2
3
4
5
6
7
8
9
10
11
12

This is useful when production logs are noisy and you want to know which problems repeat the most.

Repeated error JSON ​

Use:

bash
vix logs errors --repeated --json
1

Example output shape:

json
{
  "analyzed_lines": 120,
  "repeated_groups": 2,
  "network_disconnect_groups": 3,
  "hidden_normal_noise_lines": 18,
  "repeated_errors": [
    {
      "message": "upstream timed out",
      "count": 12
    }
  ],
  "network_disconnects": [
    {
      "name": "client disconnected",
      "count": 14
    }
  ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Use JSON output for:

  • CI
  • dashboards
  • automation
  • production monitoring experiments
  • deployment reports

Normal network disconnect noise ​

Production logs often contain normal disconnects.

Examples:

txt
broken pipe
connection reset by peer
client closed connection
client prematurely closed connection
websocket disconnected
EOF
1
2
3
4
5
6

These do not always mean your app is broken.

They often mean the client closed the connection.

vix logs errors --repeated groups this noise separately so it does not hide real repeated failures.

Normal network noise groups include:

txt
client disconnected
connection reset by peer
websocket disconnected
1
2
3

The report can show:

txt
Hidden normal noise: 18 lines
1

This helps production logs stay useful.

Network disconnect groups ​

The repeated error analyzer can group common network failures such as:

GroupMeaning
client disconnectedClient closed the connection, broken pipe, EOF, or similar.
connection reset by peerRemote side reset the connection.
websocket disconnectedWebSocket client disconnected.
upstream disconnectedUpstream closed the connection early.
connection refusedUpstream or target refused the connection.
timeoutA request or upstream timed out.

The goal is to separate normal production noise from real repeated failures.

Commands printed before execution ​

vix logs prints the command it is about to run.

Example:

txt
Command: journalctl -u pulsegrid -n 120 --no-pager
1

This makes log inspection transparent.

If you need to debug manually, you can copy the command and run it yourself.

Target behavior ​

No target ​

bash
vix logs
1

Runs:

txt
app logs
proxy access logs
proxy error logs
1
2
3

app ​

bash
vix logs app
1

Runs:

txt
systemd app logs
1

proxy ​

bash
vix logs proxy
1

Runs:

txt
Nginx access logs
Nginx error logs
1
2

errors ​

bash
vix logs errors
1

Runs:

txt
filtered app errors
Nginx error logs
1
2

It also enables error filtering internally.

Full production logs config ​

json
{
  "name": "PulseGrid",
  "production": {
    "service": {
      "name": "pulsegrid"
    },
    "proxy": {
      "domain": "pulsegrid.example.com",
      "http": {
        "port": 8080
      }
    },
    "logs": {
      "service": "pulsegrid",
      "nginx_access": "/var/log/nginx/pulsegrid.access.log",
      "nginx_error": "/var/log/nginx/pulsegrid.error.log",
      "lines": 120
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Then run:

bash
vix logs
vix logs app
vix logs proxy
vix logs errors
vix logs errors --repeated
1
2
3
4
5

Relationship with vix service ​

vix service manages the app service.

vix logs app reads logs for that service.

Typical flow:

bash
vix service status
vix logs app
1
2

After a restart:

bash
vix service restart
vix logs app -f
1
2

Relationship with vix proxy nginx ​

vix proxy nginx manages Nginx config.

vix logs proxy reads Nginx access and error logs.

Typical flow:

bash
vix proxy nginx check
vix logs proxy
1
2

If the public endpoint fails:

bash
vix proxy nginx check
vix logs proxy --errors
1
2

Relationship with vix health ​

vix health tells you whether an endpoint is healthy.

vix logs tells you why it may be unhealthy.

Typical flow:

bash
vix health
vix logs errors
vix logs errors --repeated
1
2
3

Relationship with vix doctor production ​

vix doctor production gives a readiness overview.

vix logs gives detailed runtime evidence.

Typical flow:

bash
vix doctor production
vix logs errors
1
2

Relationship with vix deploy ​

A deployment command can show logs on failure.

Manual flow:

bash
vix deploy
vix health
vix logs errors
1
2
3

If repeated failures appear:

bash
vix logs errors --repeated
1

Options ​

OptionDescription
appShow systemd app logs.
proxyShow Nginx access and error logs.
errorsShow app errors and Nginx error logs.
--followFollow logs live.
-fAlias for --follow.
--errorsFilter logs by common error keywords.
--repeatedDetect repeated errors and common network disconnect groups.
--jsonPrint supported output as JSON. Currently useful with --repeated.
--since <time>Filter app logs by a systemd time expression.
--lines <n>Show last N lines.
-n <n>Alias for --lines.
-h, --helpShow help.

Common workflows ​

Inspect everything ​

bash
vix logs
1

Inspect app logs ​

bash
vix logs app
1

Inspect proxy logs ​

bash
vix logs proxy
1

Inspect only errors ​

bash
vix logs errors
1

Follow app logs while restarting ​

bash
vix service restart
vix logs app -f
1
2

Follow proxy logs while testing public URL ​

bash
vix logs proxy -f
1

Show recent errors ​

bash
vix logs errors -n 200
1

Show errors from the last hour ​

bash
vix logs errors --since "1 hour ago"
1

Analyze repeated errors ​

bash
vix logs errors --repeated
1

Analyze repeated errors as JSON ​

bash
vix logs errors --repeated --json
1

Common mistakes ​

Running outside the project directory ​

Wrong:

bash
cd ~
vix logs
1
2

Correct:

bash
cd /path/to/myapp
vix logs
1
2

vix logs reads vix.json from the current project directory.

Expecting logs to start the service ​

vix logs only reads logs.

Start the service with:

bash
vix service start
1

Expecting logs to fix health failures ​

vix logs helps you inspect failures.

Use the right command to fix the source of the issue.

Examples:

bash
vix service restart
vix proxy nginx check
vix health local
vix health public
1
2
3
4

Using --json without --repeated ​

JSON output is currently useful for repeated error analysis.

Use:

bash
vix logs errors --repeated --json
1

Expecting --since to filter Nginx log files ​

--since is passed to journalctl for app logs.

Nginx log files are read with tail.

Forgetting sudo permissions for Nginx logs ​

Proxy logs are usually under:

txt
/var/log/nginx/
1

Vix reads them using sudo tail.

Make sure your user can use sudo.

Missing Nginx log files ​

If Vix reports that a log file is missing, check:

json
{
  "production": {
    "logs": {
      "nginx_access": "/var/log/nginx/pulsegrid.access.log",
      "nginx_error": "/var/log/nginx/pulsegrid.error.log"
    }
  }
}
1
2
3
4
5
6
7
8

or configure Nginx to write logs at those paths.

Troubleshooting ​

Missing service name ​

If app logs cannot be read, configure:

json
{
  "production": {
    "logs": {
      "service": "pulsegrid"
    }
  }
}
1
2
3
4
5
6
7

You can also define:

json
{
  "production": {
    "service": {
      "name": "pulsegrid"
    }
  }
}
1
2
3
4
5
6
7

App logs are empty ​

Check service status:

bash
vix service status
1

Then inspect directly:

bash
journalctl -u pulsegrid -n 120 --no-pager
1

Proxy access log not found ​

Check the configured path:

json
{
  "production": {
    "logs": {
      "nginx_access": "/var/log/nginx/pulsegrid.access.log"
    }
  }
}
1
2
3
4
5
6
7

Then check Nginx config:

bash
vix proxy nginx check
1

Proxy error log not found ​

Check:

json
{
  "production": {
    "logs": {
      "nginx_error": "/var/log/nginx/pulsegrid.error.log"
    }
  }
}
1
2
3
4
5
6
7

Then inspect Nginx:

bash
sudo nginx -t
1

Public URL fails ​

Run:

bash
vix health public
vix proxy nginx check
vix logs proxy --errors
1
2
3

Local app fails ​

Run:

bash
vix health local
vix service status
vix logs app --errors
1
2
3

WebSocket fails ​

Run:

bash
vix health websocket
vix proxy nginx check
vix logs errors --repeated
1
2
3

Too many disconnect messages ​

Run:

bash
vix logs errors --repeated
1

Normal disconnects are grouped separately so you can focus on actual repeated failures.

Best practices ​

Keep log configuration in vix.json.

Use vix logs app for app crashes and service startup errors.

Use vix logs proxy for Nginx and public traffic issues.

Use vix logs errors when you want failure-focused logs.

Use vix logs errors --repeated when logs are noisy.

Use vix logs app -f while restarting the service.

Use vix logs proxy -f while testing the public URL.

Use vix health before logs to know which layer is failing.

Use vix doctor production after logs to confirm readiness.

CommandPurpose
vix serviceManage the systemd app service.
vix proxy nginxManage Nginx reverse proxy configuration.
vix healthCheck local, public, and WebSocket endpoints.
vix doctor productionInspect production readiness.
vix deployDeploy the production app.
vix buildBuild the app binary.
vix runRun the app manually.

Next step ​

Check endpoint health.

Open the health guide

Released under the MIT License.

Copyright © 2026 Vix.cpp

Morty Proxy This is a proxified and sanitized view of the page, visit original site.