01
Diagnose
Understand what actually failed.
A plain-English summary, one strong root-cause hypothesis, the exact signals pulled from your log, and the alternatives worth ruling out.
Mobile incident terminal
Production broke.
You're not at your desk.
Paste the error into Terminal3. Diagnose the cause, find the fix, and verify it worked — in three passes.
Terminal3 reads what you paste. It never connects to your infrastructure.
terminal3
ReadyAnalyze
History
Runbooks
Profile
The method
Three passes. One answer.
Most tools hand you a wall of text and leave the thinking to you. Terminal3 moves in sequence, and each pass has one job.
02
Fix
Get an actionable remediation path.
Ordered steps with the commands and configuration that go with them. Destructive actions carry a warning and a safer alternative.
03
Verify
Confirm the incident is resolved.
A checklist, the commands that prove it, what a successful response looks like, and the regression checks worth running before you close it out.
Input
If it looks broken, paste it.
There is no format to learn and nothing to connect. Terminal3 reads raw text — the thing you already have in front of you.
Stack traces
Node, Python, Go, Java, Ruby, Rust.
HTTP errors
4xx and 5xx with headers and body.
API responses
JSON error envelopes from any provider.
Logs
Application, container and server output.
Deployment failures
Build output and platform errors.
Database errors
Connection, constraint, migration, lock.
Auth failures
401, 403, token and signature problems.
Webhooks
Signature mismatches and failed deliveries.
Example
In, and then out.
Raw text goes in. What comes back is a reading of it — hedged where it should be, specific where it can be.
What you pastedExample
Error: connect ECONNREFUSED 127.0.0.1:5432
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16) {
errno: -61,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 5432
}
[api] 2 requests failed in 30s — pool: 0/10 connections establishedTerminal3 · 01 Diagnose84% confidence
PostgreSQL connection refused
DatabaseHigh severityDatabase connection layer
What happened
Your application tried to open a TCP connection to PostgreSQL on 127.0.0.1:5432 and the operating system rejected it immediately. Nothing is listening on that address and port — this is a refusal, not a timeout, so the request never reached a database process.
Most likely cause
No PostgreSQL process is accepting connections at 127.0.0.1:5432 from the perspective of the running application. Most often the database isn't running, or the app is pointed at localhost while the database actually lives somewhere else — a container, another host, or a different port.
Signals
ECONNREFUSED127.0.0.15432syscall: 'connect'pool: 0/10Other possibilities
- Container networking mismatch. If the app runs in Docker, 127.0.0.1 refers to the app's own container, not the host. The database is reachable but under a different hostname — usually the compose service name.
- Postgres bound to a different interface. The server may be running but with listen_addresses set so it doesn't accept connections on the loopback address the client is using.
- Wrong port in the connection string. A second Postgres instance or a connection pooler such as PgBouncer may be on 6432 or 5433 while the app still targets 5432.
02 Fix · first step
Confirm whether anything is listening on the port
Before changing configuration, establish the basic fact: is there a process bound to 5432 on the machine the app is running from? An empty result confirms the refusal is genuine rather than a credential or TLS problem.
03 Verify · expected result
psql prints the PostgreSQL version, the application's pool reports its configured number of connections, and the previously failing endpoint returns 200 with a JSON body instead of a 500.
Bundled example analyses, written by hand and shipped with the product. Analysing your own input requires an AI provider to be configured.
Why mobile
Incidents don't wait for your laptop.
Terminal3 is intentionally designed around the moment you're away from your development environment but need to understand what just went wrong.
Scan to open
Point your camera at the code, or type the address.
terminal3.funterminal3
ReadyAnalyze
History
Runbooks
Profile
terminal3
ReadyAnalyze
History
Runbooks
Profile
terminal3
ReadyAnalyze
History
Runbooks
Profile
Trust
Your logs deserve restraint.
Terminal3 handles the most sensitive text a developer has. The honest version of what that means:
Read the privacy page- Local-first history
- Saved incidents and runbooks live in your browser's storage on this device. There is no Terminal3 account, and nothing syncs anywhere.
- A warning before you paste a secret
- Terminal3 scans your input in the browser for common credential shapes — API keys, tokens, private keys, passwords in connection strings — and warns you before anything is submitted. It's a heuristic, not a guarantee.
- What we don't claim
- No end-to-end encryption, because it isn't implemented. No zero retention, because analysis runs through a third-party model provider whose retention policy we don't control. Remove secrets before pasting production logs.
Who made this
Built for people who debug things.
Manoj Paliwal
Founder
Terminal3 started from a narrow, familiar problem: something breaks, you're not at a keyboard, and the fastest thing you can do is read an error on a small screen and decide what it means. It is built to do that one thing well.