Overview
Thelua logs command provides an interactive interface for viewing and navigating your agent’s execution logs with powerful filtering capabilities.
Looking for the canonical debug loop? See Debugging your agent for the recommended push → test → check flow that uses
lua logs as the truth source.When to run lua logs
There are three moments when lua logs is the most valuable command in the CLI:
1. Immediately after a lua chat -m "test". A chat response can look fine while the server quietly logged a billing failure, a tool exception, or an LLM provider error. Run lua logs --type agent_error --limit 5 after every test message — if the count is zero, the test passed cleanly. The CLI also runs a quiet agent_error probe automatically after each chat turn and prints a one-line warning when new errors fire (set LUA_NO_HINTS=1 to silence it).
2. After a lua push to verify a new version is healthy in production. The CLI prints a ✨ Tip: line at the end of every push pointing at the right lua logs --type X --limit 10 command for what you just deployed — follow it.
3. When investigating a user-reported issue. Filter to the affected user with --user-id <id> and to the most likely component type:
Non-Interactive Mode
| Option | Description |
|---|---|
--type <type> | Filter: all, skill, job, webhook, preprocessor, postprocessor, device, device-trigger, user_message, agent_response, agent_error, mcp, rag, runtime, calls |
--name <name> | Entity name (requires —type, not for message types) |
--user-id <userId> | Filter logs by user ID |
--agent-id <agentId> | View logs for a specific agent (overrides the agent in lua.config.yaml). Requires admin access to the target agent. |
--status <status> | Filter calls by status (completed, failed, in-progress, etc.). Only with --type calls. |
--limit <n> | Number of logs (default: 20) |
--page <n> | Page number for pagination |
--json | Output as JSON for scripting |
--agent-id is useful for inspecting logs across multiple agents you own without switching project directories. If you don’t have admin access to the requested agent, the command returns an access-denied error.Type values: Use
runtime for platform runtime logs (was previously mastra). Use rag for knowledge base search logs, device-trigger for device trigger execution logs, and calls for voice call records.agent_error vs runtime: Use --type agent_error to find pipeline failures (billing, validation, LLM provider errors) — these often don’t surface in the chat response itself. Use --type runtime for agent runtime / LLM SDK / framework-level diagnostics (low-level model and orchestration logs).Post-deploy verification recipe
agent_error --limit 5 returns no entries timestamped after your deploy, the version is healthy. If it does, read the entries before walking away. See Debugging your agent for the complete flow.
Filter by Type
Filter logs by Skills, Jobs, Webhooks, Preprocessors, or Postprocessors
See All Your Components
View logs for all your components, including dynamically created jobs
Detailed Information
See which component generated each log, including names and IDs
Color-Coded
Easily spot errors, warnings, and different log types
Log Types
- ❌ Error
- ⚠️ Warn
- 🔍 Debug
- ℹ️ Info
- ▶️ Start/✅ Complete
Execution errors and failures
- Tool execution failures
- API errors
- Invalid configurations
- Stack traces for debugging
Interactive Flow
Select Specific Component (if filtering)
All Jobs Visible: All your jobs appear in the list, including ones created dynamically in your code.
Use Cases
Debug Tool Errors
Monitor Performance
Verify Tool Execution
Track Webhook Activity
Monitor Job Execution
Example Session
Filtering by Skill
Log Entry Details
Each log entry shows you:For Skill Logs
- Skill Name - Which skill generated the log
- Skill ID - Unique identifier for the skill
- Tool Name - Which tool was running (if applicable)
- Timestamp - When the log was created
- Log Type - Error, debug, info, warn, start, or complete
- Message - The actual log message
- Duration - How long the operation took (for completed operations)
For Job Logs
- Job Name - Which job generated the log
- Job ID - Unique identifier for the job
- Timestamp - When the log was created
- Log Type - Error, debug, info, warn, start, or complete
- Message - The actual log message
- Duration - How long the job took to run
For Webhook, Preprocessor, and Postprocessor Logs
- Name - Which component generated the log
- ID - Unique identifier
- Timestamp - When the log was created
- Log Type - Error, debug, info, warn, start, or complete
- Message - The actual log message
- Duration - How long the operation took
Tool Information: Tool names are only shown for skill logs, since tools belong to skills.
Navigation Options
- Next Page →
- ← Previous Page
- 🔢 Go to specific page
- 🔄 Refresh
- ❌ Exit
View the next page of logsDisabled if on last page
Best Practices
Start with All Logs
Start with All Logs
Monitor After Deployment
Monitor After Deployment
Debug Specific Issues
Debug Specific Issues
Track Performance
Track Performance
Troubleshooting
No logs available
No logs available
Causes:
- Skills not deployed yet
- Agent hasn’t been used
- Viewing wrong agent
Can't find specific error
Can't find specific error
Try:
- Navigate through pages using the navigation menu
- Filter by the specific component (skill, job, etc.)
- Check the most recent pages first (page 1)
- Look at the timestamp to find when the error occurred
Logs not updating
Logs not updating
Use refresh:Reloads current page with latest data
Integration with Workflow
During Development
After Deployment
Debugging Issues
Related Commands
Debugging Loop
Canonical push → test → check flow
lua chat
Test agent (generates logs + auto agent_error probe)
lua test
Test tools locally (no remote logs)
lua push
Deploy skills (required for logs)
Next Steps
Test Your Agent
Generate logs to view
Deploy Skills
Push skills to generate logs
Troubleshooting
Common issues and solutions
Production Monitoring
Monitor production environment

