You debug it. Or AI does.

LogNorth gives agents the same context you'd read yourself.

Open the logs. Scroll. Search. Find the error. Context-switch to code. Trace it. Fix it. Deploy. Check if it worked.
$ agent "payments are failing in checkout"

[agent] Querying LogNorth for recent errors...
[agent] Found: Stripe::CardError in payment_service.rb:67 (23 hits, last 4m)
[agent] Stack: checkout_controller.rb:23 → payment_service.rb:67 → charge!
[agent] Reading codebase...
[agent] Root cause: live mode request with test card token
[agent] Writing fix...
[agent] Tests pass. Deploying.
[agent] Verified: 0 errors in last 5 minutes.

Done. // an example session

Why this works if you're solo.

The bug is in 1 of 200 files. The stack trace is 14 frames deep. You need to cross-reference 3 log entries across 2 services. That is all context-loading, before you write a single fix.

Your codebase fits in a context window. The agent reads your errors, traces the call stack, greps your code, and writes the patch.

What the agent reads.

The same data you'd read, as a tool result. No dashboard required.

tool list_issues

{
  "issues": [{
    "error":       "Your card was declined.",
    "error_class": "Stripe::CardError",
    "error_file":  "app/services/payment_service.rb",
    "error_line":  67,
    "count":       23,
    "count_24h":   23,
    "first_seen":  "2026-03-29 14:28:00",
    "last_seen":   "2026-03-29 14:32:01",
    "trend":       "up",
    "active":      true
  }]
}

The logs around it too, every line that led to it.

The full picture.

The agent reads the logs around the failure. Every line you wrote, in order.

logs: req-8f3a2b

14:32:01.003  POST /checkout                         12ms
14:32:01.015  Stripe::PaymentIntent.create            847ms
14:32:01.863  Stripe::CardError                      payment_service.rb:67

pattern: 23 occurrences in 4 minutes, all from /checkout
trend:   ↑ up

Steps, timing, patterns, repetitions. The agent sees the spike, reads the logs, finds the root cause.

Three lines. Your agent is connected.

LogNorth speaks MCP at /mcp, inside the server you already run. The plugin installs the tools and the skills that read them, and /lognorth:connect points them at your server.

> /plugin marketplace add karloscodes/lognorth-releases
> /plugin install lognorth
> /lognorth:connect

Connected. // 4 tools + 2 skills, no binary to keep updated

Cursor, VS Code, Gemini CLI, Windsurf, Codex and Zed take the same endpoint. The MCP docs have the exact config for each one.

The agent gets four tools: list_apps for your apps, search_logs to find the failing requests, get_event for one request with its whole trace, and list_issues for what is broken right now.

Then ask: "what's breaking in production?"

Every tool is read-only. The agent can read events and issues, and there is no tool to change one. Your logs stay on your server: the agent asks your instance, and only the answer reaches your AI provider.

Read the error. Trace the cause. Write the fix. Verify the deploy.

Four steps. Zero tabs.