Loading
Examples
These are the analyses that ship with Terminal3. They're written by hand rather than generated, so they behave identically every time — and they run without an API key.
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 establishedWhat 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
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.
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.
ECONNREFUSED127.0.0.154325 fix steps3 checks
The /api/orders handler threw a TypeError while reading .id from a value that was undefined, and nothing caught it — so the framework returned a generic 500. The failure is in your own code at orders.ts:42, not in the framework or the client.
TypeError: Cannot read properties of undefinedreading 'id'orders.ts:42:314 fix steps3 checks
The browser sent an OPTIONS preflight to api.example.com before the real request, and the API answered 404 with no CORS headers. Because the preflight failed, the browser blocked the actual request — so your server never saw it. This is a server response problem, not a bug in your fetch call.
blocked by CORS policyResponse to preflight request doesn't pass access control checkNo 'Access-Control-Allow-Origin' header4 fix steps3 checks
The API rejected the request because the JWT it received had already expired — roughly 28 minutes past its expiry at the time of the call. The token was well-formed and correctly signed; it was simply too old. This is a token lifecycle problem, not a credentials problem.
401 Unauthorizederror="invalid_token"error_description="token is expired"4 fix steps3 checks
A batch job burned the entire 600-request quota and then received 429s for the remaining 182 items. The API is telling you exactly how long to wait — 17 seconds — via the retry-after header. The requests aren't failing on their merits; they're arriving faster than your allowance permits.
HTTP/2 429retry-after: 17x-ratelimit-limit: 6004 fix steps3 checks
The signature check rejected an incoming webhook. The error names the most common cause directly: the body being verified is not byte-for-byte what the sender signed. Almost always a JSON body-parser has already run and re-serialised the payload before verification.
Webhook signature verification failedNo signatures found matching the expected signatureAre you passing the raw request body5 fix steps3 checks