Monitor results analysis in Postman - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the result status of this Postman monitor run?

Given this Postman test script snippet inside a monitor run, what will be the test result status shown in the monitor report?

Postman

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
pm.test("Response time is less than 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

A Pass if response status is 200 and response time is below 500ms; otherwise fail

B Pass if either response status is 200 or response time is below 500ms

C Fail if response status is 200 but response time is above 500ms

D Always pass regardless of response status or time

💡 Hint

Each pm.test defines a separate assertion that must pass for the monitor to pass.

In Postman monitors, all pm.test assertions must pass for the test to be considered successful. Both status code and response time checks are separate tests and both must pass.

❓ assertion

intermediate

Which assertion correctly checks JSON response contains a key 'userId' with value 5?

You want to verify in a Postman monitor that the JSON response body has a key 'userId' equal to 5. Which assertion code is correct?

A pm.expect(pm.response.json().userId).to.eql(5);

B pm.response.to.have.jsonBody('userId', 5);

C pm.expect(pm.response.body.userId).to.equal(5);

D pm.expect(pm.response.json().userId).to.be.above(5);

💡 Hint

Use pm.response.json() to parse JSON body before checking keys.

pm.response.json() parses the response body as JSON. Then you can access keys like userId. The assertion to.eql(5) checks exact equality.

🔧 Debug

advanced

Why does this Postman monitor test always fail?

This Postman test script is inside a monitor but always fails. What is the cause?

Postman

pm.test("Check user name", function () {
    pm.expect(pm.response.json().name).to.equal("John");
});

pm.test("Check user age", function () {
    pm.expect(pm.response.json().age).to.be.above(18);
});

pm.test("Check user active", function () {
    pm.expect(pm.response.json().active).to.be.true;
});

A The tests run asynchronously and cause race conditions.

B The assertion pm.expect(...).to.be.true is invalid syntax in Postman.

C The pm.response.json() method cannot be called multiple times.

D The response JSON does not contain the key 'active', causing an assertion error.

💡 Hint

Check if all keys exist in the response JSON before asserting.

If the 'active' key is missing, pm.response.json().active is undefined. Using to.be.true on undefined causes the test to fail with an error.

🧠 Conceptual

advanced

What does a 'failed' status in Postman monitor results indicate?

In Postman monitor results, what does a 'failed' status mean?

A The response status code was 200 but response time was slow.

B At least one pm.test assertion failed during the monitor run.

C The monitor did not run due to scheduling errors.

D All pm.test assertions passed but the response body was empty.

💡 Hint

Monitor status depends on test assertions, not scheduling or response content alone.

A 'failed' status means one or more pm.test assertions did not pass during the monitor execution.

❓ framework

expert

How to programmatically analyze Postman monitor results via API?

You want to automate analysis of Postman monitor results. Which approach correctly uses Postman API to fetch monitor run results?

A Send a GET request to https://api.getpostman.com/collections/{{monitor_uid}}/runs with API key in headers.

B Send a POST request to https://api.getpostman.com/monitors/{{monitor_uid}}/results with API key in body.

C Send a GET request to https://api.getpostman.com/monitors/{{monitor_uid}}/runs with API key in headers.

D Send a DELETE request to https://api.getpostman.com/monitors/{{monitor_uid}}/runs to get results.

💡 Hint

Use GET method and correct endpoint to retrieve monitor runs.

The Postman API endpoint to get monitor runs is a GET request to /monitors/{{monitor_uid}}/runs with the API key in headers.

Practice

1. What is the main purpose of analyzing Postman monitor results?

easy

A. To create user interface designs

B. To write new API requests

C. To track API health and detect failures over time

D. To deploy applications to servers

Solution

1. Step 1: Understand monitor results role

   Monitor results show how API tests perform over time, highlighting issues.

2. Step 2: Identify main goal of analysis

   Analyzing results helps track API health and find failures quickly.

3. Final Answer:

   To track API health and detect failures over time -> Option C

4. Quick Check:

   Monitor results = API health tracking [OK]

Hint: Monitor results show API health trends over time [OK]

Common Mistakes:

• Confusing monitor results with request creation
• Thinking monitor results are for UI design
• Assuming monitor results deploy apps

2. Which filter option in Postman Monitor results helps you quickly find failed test runs?

easy

A. Sort by request name

B. Sort by creation date

C. Filter by response time

D. Filter by status: Failed

Solution

1. Step 1: Identify filter purpose

   Filtering by status narrows results to specific outcomes like failures.

2. Step 2: Choose filter to find failures

   Filtering by status: Failed shows only failed test runs quickly.

3. Final Answer:

   Filter by status: Failed -> Option D

4. Quick Check:

   Status filter = find failures fast [OK]

Hint: Use status filter to isolate failures fast [OK]

Common Mistakes:

• Sorting by request name does not isolate failures
• Filtering by response time shows speed, not failures
• Sorting by creation date orders runs but doesn't filter failures

3. Given this Postman monitor result snippet:

{"runId":123, "status":"failed", "tests": {"responseCodeCheck": false, "bodyCheck": true}}

Which test failed in this run?

medium

A. bodyCheck

B. responseCodeCheck

C. Both tests passed

D. No tests were run

Solution

1. Step 1: Read test results in JSON

   The tests object shows responseCodeCheck: false and bodyCheck: true.

2. Step 2: Interpret boolean test results

   false means test failed, true means test passed.

3. Final Answer:

   responseCodeCheck -> Option B

4. Quick Check:

   False test = failure [OK]

Hint: False test result means failure [OK]

Common Mistakes:

• Assuming true means failure
• Ignoring test result booleans
• Confusing test names

4. You notice your Postman monitor shows all runs as "passed" but your API is down. What is the most likely cause?

medium

A. Test scripts do not check API response status codes

B. Monitor is not scheduled to run

C. API is running but returning errors

D. Monitor results are delayed by 24 hours

Solution

1. Step 1: Analyze monitor showing all passes

   If monitor shows all passes but API is down, tests likely miss failure detection.

2. Step 2: Identify missing test checks

   Not checking response status codes means failures go unnoticed.

3. Final Answer:

   Test scripts do not check API response status codes -> Option A

4. Quick Check:

   Missing status checks = false passes [OK]

Hint: Check if tests verify response status codes [OK]

Common Mistakes:

• Assuming monitor is not running without checking
• Thinking API is up despite errors
• Believing monitor results delay causes issue

5. You want to create a Postman monitor report that highlights only failed tests with response times over 2 seconds. Which approach best achieves this?

hard

A. Filter monitor results by status: Failed and response time > 2000ms

B. Sort monitor results by response time ascending

C. Filter monitor results by status: Passed only

D. Export results and manually check response times

Solution

1. Step 1: Understand filtering needs

   You want to see only failed tests with slow response times.

2. Step 2: Apply combined filters

   Filtering by status: Failed and response time > 2000ms shows exactly those runs.

3. Final Answer:

   Filter monitor results by status: Failed and response time > 2000ms -> Option A

4. Quick Check:

   Combined filters = precise failure + slow tests [OK]

Hint: Use combined filters for precise monitor analysis [OK]

Common Mistakes:

• Sorting alone does not filter failures
• Filtering by passed misses failures
• Manual checks waste time and risk errors