failure.internal

Our fault: a bug, a failed database call. The caller gets a generic message; the details go to the log

Profile

Raised with

Status

500

Message

generic

Example

TS
return fail('failure.internal', undefined, { cause: error });
The caller gets
Terminal
HTTP 500

{
"ok": false,
"error": "Something went wrong. Try again.",
"code": "failure.internal"
}
And it writes incident.failed
TS
{
"intent": "incident.failed",
"level": "error",
"alert": true,
"message": "Something went wrong. Try again.",
"data": {
"intent": "failure.internal",
"cause": {
"name": "PostgresError",
"message": "connection terminated unexpectedly",
"stack": "PostgresError: connection terminated…"
}
},
"time": "2026-10-09T12:00:00.000Z"
}

Choosing between neighbours

Find the row that describes your case, and use the intent on the right.

  • If it is

    Use

  • Our fault: a bug, a failed database call. The caller gets a generic message; the details go to the log

    failure.internal this page
  • Anything the caller did wrong

    request.invalid

Connections

Declared in the registry, both directions. Where an intent is used in your own code is something check and the gallery see; this site has no app code.

For registry authors

Starter intents. These are the intents prongs add errors puts in your registry, raised with fail(). Change the messages to suit your app, and the statuses through the status.* intents they are built from.

The entry prongs add errors writes into your registry. Change the message here, or the status through its status.* ref.

TS
'failure.internal': {
kind: 'semantic',
description: 'Our fault: a bug, a failed database call. The caller gets a generic message; the details go to the log',
refs: ['status.internal'],
keywords: ['crash', 'exception', 'database', 'bug'],
binding: {
publicMessage: 'Something went wrong. Try again.',
logs: 'incident.failed',
},
notFor: [
{ context: 'anything the caller did wrong', instead: 'request.invalid' },
],
},