Scheduling gRPC and GraphQL Requests with Postman Monitors (Beta)

If you run gRPC or GraphQL services in production, you’ve probably hit this wall: your Postman Collection already has the request configured with the right auth, variables, and Test Scripts, but when you go to schedule it as a Monitor, only HTTP requests show up. So you end up either writing a separate synthetic check in a different tool, or building a small script that shells out to a CLI on a cron somewhere. Both work. Neither feels great.

That gap is closing. Postman Monitors now run gRPC and GraphQL requests in beta. I’ll walk through how to schedule a gRPC call (including streaming), how to monitor a GraphQL query or mutation, what your Test Scripts look like for each, and where to send feedback while the feature is still in progress.

What’s in the beta

Here’s what the beta covers today:

• gRPC unary calls, the standard request/response pattern.
• gRPC server-streaming, client-streaming, and bidirectional, with some caveats on the streaming side that I’ll get to.
• GraphQL queries and mutations over HTTP.
• Existing auth, variables, and Test Scripts, which carry over from your Collection with no rewrites needed.

What’s not in yet: GraphQL subscriptions, multi-message client streaming, and richer stream assertion helpers. Those are on the roadmap.

Worth noting: this is the same Monitors execution model you already know. The scheduler picks up your Collection, runs the requests in order, evaluates your Test Scripts, and posts results. The only thing that changed is the set of protocols the runner understands.

Monitoring a gRPC call

Let’s start with the simplest case: a unary gRPC call to a user service. You’ve already got the request in your Collection, connected to a .proto file, with a method selected. To schedule it, right-click the Collection, choose Create a monitor, and set the schedule you want.

For validation, gRPC responses go through the same pm.response object you use for HTTP tests. The properties are just shaped for gRPC:

pm.test("Status is OK", () => {
  pm.expect(pm.response.code.name).to.eql("OK");
});
pm.test("User has an id", () => {
  const message = pm.response.messages()[0]?.data;
  pm.expect(message).to.have.property("id");
  pm.expect(message.id).to.be.a("string");
});
pm.test("Response arrived in under 500ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

If the gRPC status comes back as anything other than OK, such as UNAVAILABLE, DEADLINE_EXCEEDED, or PERMISSION_DENIED, your Monitor fails and you get notified. That’s the useful default. In practice I also assert on message shape, because a healthy status with an empty payload is still a broken endpoint from the caller’s perspective.

For authentication, if you’re using gRPC metadata for Bearer tokens, configure it once on the request and it travels with the Monitor run. Store the token itself in a Monitor Environment variable, never in the request definition.

Monitoring gRPC streams

Streaming is where this gets interesting. Server-streaming is the sweet spot in the beta: you send one message, the server sends many, and you can assert on messages as they arrive.

You have two options for testing. The first is the On message script hook, which runs for each message the server sends:

// On message script, runs for every streamed message
const message = pm.response.messages().at(-1)?.data;
pm.test(`Message ${pm.response.messages().length} has a timestamp`, () => {
  pm.expect(message).to.have.property("timestamp");
});

The second is asserting after the stream completes, in your regular Tests tab:

pm.test("Stream returned at least 5 events", () => {
  pm.expect(pm.response.messages().length).to.be.at.least(5);
});
pm.test("Stream closed cleanly", () => {
  pm.expect(pm.response.code.name).to.eql("OK");
});

I lean toward the post-stream assertions for Monitors specifically. Per-message checks are useful when you’re debugging live in the client, but when a Monitor fails at 3am, “the stream returned 2 messages instead of 5” is a much clearer signal than 20 individual per-message assertion results.

Heads up on client-streaming and bidirectional: the beta currently supports one client message per call. If your bidirectional flow depends on sending a sequence of messages back to the server, wait for the multi-message update before moving that check into a Monitor. Unary and server-streaming are the paths that work end-to-end today.

Monitoring a GraphQL query or mutation

GraphQL requests are HTTP under the hood, but the failure model is different enough that it’s worth calling out. A GraphQL server can return 200 OK with a body full of errors, so a status-code check alone will happily pass while your API is broken.

Here’s a query I use as a template for GraphQL Monitors:

pm.test("HTTP status is 200", () => {
  pm.expect(pm.response.code).to.eql(200);
});
pm.test("No GraphQL errors", () => {
  pm.expect(pm.response.errors, JSON.stringify(pm.response.errors)).to.be.undefined;
});
pm.test("Query returned the expected shape", () => {
  const data = pm.response.data;
  pm.expect(data).to.have.property("viewer");
  pm.expect(data.viewer).to.have.property("id");
  pm.expect(data.viewer.repositories.nodes).to.be.an("array");
});

pm.response.data and pm.response.errors are the two properties that matter most here. Together they tell you whether the operation actually succeeded from the client’s point of view, which is what a Monitor should be checking anyway.

For a mutation, I’d also assert on the returned entity to catch cases where the server accepts the mutation but silently drops fields. Something like:

pm.test("Mutation returned the new order", () => {
  const order = pm.response.data?.createOrder;
  pm.expect(order).to.have.property("id");
  pm.expect(order.status).to.eql("pending");
  pm.expect(order.lineItems).to.have.lengthOf.at.least(1);
});

Subscriptions aren’t in the beta yet. If you rely on them, keep your existing subscription check in place for now.

Setting the schedule

Once your requests have tests, scheduling is the same as any other Monitor. Pick a frequency (every 5 minutes up to weekly), choose a region if you care about geographic coverage, attach an Environment with your credentials, and turn on notifications. I usually start with a 15-minute cadence for a new Monitor and tighten it once I’ve seen a week of clean runs. Running expensive queries every minute during setup adds up quickly.

Two tips from running this on my own services:

1. Use a dedicated Monitor Environment. Don’t reuse your local dev environment. Create one with just the variables the Monitor needs, use secret variables for tokens, and rotate them on the same schedule you rotate everything else.
2. Keep the Collection focused. A Monitor should check one thing: a critical read, a health-check mutation, or a streaming heartbeat. If it fails, you want to know exactly what broke. A 30-request Collection with one failing test in the middle is a debugging exercise you don’t want at 3am.

Sending feedback during the beta

This is a beta, and the team is actively listening. If you hit a rough edge, such as a script hook that doesn’t behave, a .proto file that won’t upload, or a metric you wish was on the run report, open an issue on the postman-app-support repo on GitHub. Tag it clearly (gRPC or GraphQL, Monitors) and include the Collection structure and any error output. The specific asks the team has flagged as most useful:

• Which streaming patterns you’d want to see supported next
• GraphQL subscription use cases you’d move into Monitors if they were available
• Assertion helpers you’d want for streamed responses

The roadmap already includes multi-message client streaming, GraphQL subscriptions, and richer stream assertions, but ordering depends on what people are actually trying to do.

Wrapping up

The short version: if you had a gRPC or GraphQL request sitting in a Collection that you wanted to run on a schedule, you can now do that without switching tools. Unary gRPC, server-streaming gRPC, and GraphQL queries and mutations are ready. Multi-message client streaming, bidirectional streaming with multiple messages, and GraphQL subscriptions are on the way.

What I like about this release is that it doesn’t ask you to rewrite anything. The same request, the same auth, the same Test Scripts, they just work on a schedule now. That’s the right way to ship a Monitors feature.

Try it against a service you actually care about, watch a few runs go by, and file an issue with what you’d want next. Betas move faster when the feedback is specific.

Resources

• Postman Monitors documentation: Overview of how Monitors work, scheduling options, and notification setup.
• Writing tests in Postman: Reference for pm.test, pm.response, and the scripting model that gRPC and GraphQL Monitors use.
• gRPC in Postman: How gRPC requests, .proto files, and streaming work in the Postman client.
• GraphQL in Postman: How to build and send GraphQL queries and mutations in a Collection.
• postman-app-support issues on GitHub: Where to file beta feedback, bugs, and feature requests.
• gRPC official documentation: Background on unary, server-streaming, client-streaming, and bidirectional RPC patterns.