Which logging members does Postman's sandbox console expose, and what actually differs between them?

middleshould knowfreq 44%

answer

Six members, one of them not logging
The differences are smaller than they look
Level is a field, not a destination
log, warn, debug, info, error, clear

basics

~10 s

PostmanConsole builds six members: log, warn, debug, info, error and clear. The five logging ones differ only in the level field on the identical execution.console event they dispatch, not in destination, stream or transport.

solid answer

~40 s

The console in a Postman script is built by PostmanConsole and exposes log, warn, debug, info, error and clear. Every one of them dispatches an execution.console event carrying the execution cursor, the level and the serialised arguments. The five logging members are therefore the same operation with a different value in one field — choosing error over log does not open a second stream, change the receiver, or make the message harder to lose. clear is the same event shape asking the receiver to discard what it is showing. Whether a level is coloured, filtered or ignored is decided by whatever embeds the sandbox, so the level is a label for a human reader rather than a routing decision.

The `console` in a Postman script is built by `PostmanConsole` and exposes `log`, `warn`, `debug`, `info`, `error` and `clear`. Every one of them **dispatches an `execution.console` event** carrying the execution cursor, the level and the serialised arguments. The five logging members are therefore the same operation with a different value in one field — choosing `error` over `log` does not open a second stream, change the receiver, or make the message harder to lose. `clear` is the same event shape asking the receiver to discard what it is showing. Whether a level is coloured, filtered or ignored is decided by whatever embeds the sandbox, so the level is a label for a human reader rather than a routing decision.

code

javascript · 6 lines

javascript

console.log('plain');
console.info('informational');
console.debug('detail');
console.warn('suspicious');
console.error('broken');
console.clear();

go deeper

for a junior

Know the names you can call: log, warn, debug, info and error, plus clear. Do not assume any of them behaves like a print statement in a normal program.

for a middle

Explain that all six dispatch the same execution.console event and that the level is one field on it, so the choice changes a label rather than a destination or a transport.

for a senior

Demonstrate that you never lean on a level for reliability, and that you keep messages self-describing because filtering and formatting are the host's decisions, not yours.

for a principal

Set the convention for a team: agree what each level means for readers, and make sure nothing in a run's behaviour is allowed to depend on which level a message carried.

One console object, six members

The console a Postman script sees is built by PostmanConsole, and it exposes exactly six members: log, warn, debug, info, error and clear. There is no hidden seventh transport behind any of them. Each call dispatches an execution.console event out of the sandbox, carrying the execution's cursor, the level, and the serialised arguments.

That single sentence answers most of what people actually want to know, because the interesting part is not the list of names — it is how little separates them.

The five logging members differ in one field

member	what the call does	what is different about it
`log`	dispatches an `execution.console` event	level recorded as `log`
`info`	dispatches an `execution.console` event	level recorded as `info`
`debug`	dispatches an `execution.console` event	level recorded as `debug`
`warn`	dispatches an `execution.console` event	level recorded as `warn`
`error`	dispatches an `execution.console` event	level recorded as `error`
`clear`	dispatches a console event too	asks the receiver to discard what it shows

Read the middle column: it never changes. Choosing error over log does not open a second stream, does not change the ordering, does not change who receives the message, and does not change whether anything else in the run notices. It changes one field on an otherwise identical event.

The level is a label, not a destination

Because the level travels as data, the meaning it acquires is assigned outside the sandbox. A receiving host is free to:

colour or icon the message differently per level;
filter some levels out of what it displays;
treat every level identically;
ignore the message altogether, having no display at all.

None of that is the sandbox's decision, and none of it is observable from inside the script. This is why "use error so it definitely shows up" is a wish rather than a mechanism.

clear is worth calling out separately for the same reason. It does not erase anything the sandbox holds — the sandbox holds nothing. It is a request, sent as an event, that whatever is displaying console messages discard what it currently shows. A host is as free to ignore that as it is to ignore a debug line.

What this means when you pick a member

Pick for the human reader, not for the plumbing. The level's only job is to help whoever is reading triage a wall of messages. Choose warn because a person should look twice, not because you believe it travels differently.
Do not encode meaning in the choice that the run must act on. Nothing downstream of the sandbox is obliged to treat error as significant, so a run's behaviour must never hinge on it.
Be sparing with clear. Wiping a display mid-run destroys context a reader may have been relying on, and it is the one member whose effect is purely destructive.
Keep the message self-describing. Since you cannot control how much surrounding context the host shows, put the identifying detail in the message itself.

Common misreadings

Claiming console.error writes to a separate error stream. The sandbox has no streams; only the recorded level differs.
Assuming a debug message is suppressed by the sandbox unless something enables it. The dispatch happens regardless; filtering, if any, belongs to the receiver.
Expecting console.clear to reset state inside the sandbox. It is a message to a display.
Reaching for members that are not there. The set that PostmanConsole builds is those six, and an unfamiliar name is not quietly emulated for you.

## One console object, six members The `console` a Postman script sees is built by `PostmanConsole`, and it exposes exactly six members: `log`, `warn`, `debug`, `info`, `error` and `clear`. There is no hidden seventh transport behind any of them. Each call **dispatches an `execution.console` event** out of the sandbox, carrying the execution's **cursor**, the **level**, and the **serialised arguments**. That single sentence answers most of what people actually want to know, because the interesting part is not the list of names — it is how little separates them. ## The five logging members differ in one field | member | what the call does | what is different about it | |---|---|---| | `log` | dispatches an `execution.console` event | level recorded as `log` | | `info` | dispatches an `execution.console` event | level recorded as `info` | | `debug` | dispatches an `execution.console` event | level recorded as `debug` | | `warn` | dispatches an `execution.console` event | level recorded as `warn` | | `error` | dispatches an `execution.console` event | level recorded as `error` | | `clear` | dispatches a console event too | asks the receiver to discard what it shows | Read the middle column: it never changes. Choosing `error` over `log` does not open a second stream, does not change the ordering, does not change who receives the message, and does not change whether anything else in the run notices. It changes **one field** on an otherwise identical event. ## The level is a label, not a destination Because the level travels as data, the meaning it acquires is assigned **outside** the sandbox. A receiving host is free to: - colour or icon the message differently per level; - filter some levels out of what it displays; - treat every level identically; - ignore the message altogether, having no display at all. None of that is the sandbox's decision, and none of it is observable from inside the script. This is why "use `error` so it definitely shows up" is a wish rather than a mechanism. `clear` is worth calling out separately for the same reason. It does not erase anything the sandbox holds — the sandbox holds nothing. It is a request, sent as an event, that whatever is displaying console messages discard what it currently shows. A host is as free to ignore that as it is to ignore a `debug` line. ## What this means when you pick a member 1. **Pick for the human reader, not for the plumbing.** The level's only job is to help whoever is reading triage a wall of messages. Choose `warn` because a person should look twice, not because you believe it travels differently. 2. **Do not encode meaning in the choice that the run must act on.** Nothing downstream of the sandbox is obliged to treat `error` as significant, so a run's behaviour must never hinge on it. 3. **Be sparing with `clear`.** Wiping a display mid-run destroys context a reader may have been relying on, and it is the one member whose effect is purely destructive. 4. **Keep the message self-describing.** Since you cannot control how much surrounding context the host shows, put the identifying detail in the message itself. ## Common misreadings - Claiming `console.error` writes to a separate error stream. The sandbox has no streams; only the recorded level differs. - Assuming a `debug` message is suppressed by the sandbox unless something enables it. The dispatch happens regardless; filtering, if any, belongs to the receiver. - Expecting `console.clear` to reset state inside the sandbox. It is a message to a display. - Reaching for members that are not there. The set that `PostmanConsole` builds is those six, and an unfamiliar name is not quietly emulated for you.

If the level does not change the destination, what is it for?
It is a label carried on the event so that whoever receives it can triage. A host may colour levels differently, filter some out, or treat them all alike — that choice lives entirely outside the sandbox. Pick a level for the benefit of the person reading, and never on the assumption that a higher level travels more reliably.
What does console.clear actually clear?
Nothing inside the sandbox, which holds no console state. It dispatches a console event asking whatever is displaying messages to discard what it currently shows. The receiver is as free to ignore that request as any other message, so it is a suggestion to a display rather than an operation on the run.

saying these in an interview costs you the question

Claims console.error writes to a separate error stream
Says the sandbox suppresses debug unless something enables it
Expects console.clear to reset state inside the sandbox
Assumes a higher level guarantees the message is shown
Invents console members the sandbox does not build

Which logging members does Postman's sandbox console expose, and what actually differs between them?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One console object, six members

The five logging members differ in one field

The level is a label, not a destination

What this means when you pick a member

Common misreadings

▾common follow-ups2 questions

▾red flags5 flags

One console object, six members

The five logging members differ in one field

The level is a label, not a destination

What this means when you pick a member

Common misreadings

answer

go deeper