DEV Community: Saransh Dhingra

Postman Monitors - Get a Slack message with the results of your run

Saransh Dhingra — Sun, 10 Jan 2021 14:35:04 +0000

If you don't know how to create Postman Monitors, kindly follow this post and continue here.

So, last time we created a monitor that checks at regular intervals if our website is up or not.

But, if you think about it, its usability is limited by the fact that we get to know about it only when we check the past results. I mean you do get emails when your test fails, but that's about it. It's limited and not a lot of customization room exists.

In this post, we aim to do just that, we want to get a Slack message when our website goes down.

There are 2 ways to this:

The easy way (Postman Integrations):

Well, as it turns out the team at Postman anticipated that I would someday write this post and they went back in time to create an easy way to do this(Trust me, I won't lie to you).

You can use something called Integrations to get Monitor Run Results to your Slack Channel.

If you can't find the 'Integrations' tab, then the url looks like this: https://your-workspace-string.postman.co/integrations/browse

But there are some drawbacks to it:

Integrations are available on Postman Team, Business, and Enterprise plans.
You can't customize it, you'd get all results to your slack channel from now on. Suppose you want to send the Slack message conditionally (say you want to send these details only on alternate days, you'd have to create different monitors).

The hard(pronounced cooler) way:

Basically, we're going to create a new request in your Postman Collection which will send information to your slack channel. So, just like in the previous method you do have to create a SlackBot capable of sending messages to your slack channel.

Check out this article to create a Slack Bot that has permissions to send a slack message to your channels using a custom webhook.

Take a note of that webhook URL and save it in a new environment that we would be using for our monitors. Save the URL in a variable named slackWebhook as seen below.

1. Create a new request in your collection which will handle sending messages to slack

2. Add details in the URL and body fields.

The request verb should be POST.
The URL should contain your webhook URL. We use the environment variable which we created earlier.

TIP: If your current environment is selected properly, your variable names should autocomplete.

Put the body type as Raw and select JSON from the dropdown. Put the content as {"text":"Any awesome text here"}
Hit send

If you receive an OK response, then your webhook URL is setup perfectly. If you receive an error, congrats, you have broken the way Slack/Postman works and you may be eligible for a bounty reward!
JK! Check your environment variables, quotes and other details.

3. Make the Slack message contents dynamic.

In the body contents instead of hardcoding the message like we did in the previous step, use something like this:

{"text":"{{slackMsg}}"}

We're basically instructing Postman to receive this value from the environment variables.

You may be thinking, like my current manager:

Aha! You haven't added the variable in the environment but you're using it! You are stupid! (Yes he says that a lot! FML)

Well, we aim to generate this text dynamically, so... Awkward!

4. Set the Slack response based on the status code.

Go to the Tests tab of the request which we defined previously(the one that actually hits your URL to be inspected).

Modify the content of the tab to contain this:

// Get the status code os the response
let statusCode=pm.response.code;

// Set the contents of the slack message dynamically
pm.environment.set('slackMsg',getSlackMsg(statusCode));

// If the status code was 200, don't send the Slack message
if(statusCode===200){
    postman.setNextRequest(null);
}

// Definition of what message to send on slack
function getSlackMsg(code){
    return code===200 ? 'Everything is awesome!' : 'Uh Oh! There is something fishy with your website!';
}

Let me explain what's happening here:

First we get the status code and store it in a temp var.
Now, we call the func getSlackMsg and get the message to send. You can modify this func to return swear words for your IT admin(Don't do that, that's rude)!
In the same instruction, we set this dynamic content into an environment variable which we talked about earlier(Smug Smile).
In the end we use a trick to terminate the series of requests to be executed using postman.setNextRequest(null);

postman.setNextRequest is very helpful in defining the flow of control between multiple requests. Read about it here.

5. Change the environment of your monitor.

Previously, our monitor was using No Environment, we need to change that, go to our defined monitor and edit it to use our newly created environment.

6. Done. Let's test the heck out of this.

Well, you don't have to wait for the Monitor Run to test this. Simply go to your collection and click Run, this would emulate how a monitor runs your request(except for IP/machine differences etc).

If your website is up, you should see only 1 request in the list of requests that ran(remember we only send slack message if something is wrong).

To emulate that, simply remove that conditional check from the Tests tab, save the request and re-run the Collection, you should see 2 requests which ran and should also receive a message in the defined slack channel.

Conclusion

We got an introduction on how to make decisions in the Tests tab of the Postman Request. We added dynamic data in our environment which we computed using the response from one of the executed requests. Then we use that dynamic content to send the information to our slack channel which we created for our Slack workspace.

This was a good introduction to get used to creating custom workflows. We will get into details in this in another post.

Postman Monitors - The hidden gem

Saransh Dhingra — Tue, 22 Dec 2020 20:52:53 +0000

Postman is a great tool. I have been using it since it was just a browser extension and really loved the idea of testing my APIs before giving it to the frontend folks.

It has been a great help while I was learning about APIs and how to create them.

It has come a long way since then. Now, there are much more things like Mocks, Monitors etc (Actually they have been around a while but not the most popular).

In this post, I would specifically like to highlight how we can use Postman Monitors for some super cool things.

Before I begin, I feel obligated to point out that I am a Postman employee, but its not in my job description, nor have I been asked by anyone to write such a post. I do so, with my own free will(like Lucifer wanted us humans to have :P )

What are Postman Monitors?

So, monitors in the postman arsenal are in my opinion one of the most powerful weapons, one which we can choose to automate any kind of work(well most of them anyway).

Want to make sure your website isn't down every few minutes?
Want to run a series of tests on your APIs on regular intervals?
Want to be notified when a product is available on Amazon?
Want to set up a reminder when your favorite crypto reaches a benchmark(Go Litecoin).

It has got you covered!

Think of monitors as your serverless cron job alternatives, where you can customize what to do, when to do it, and what to do after it has been done!

I hope you're with me on this weird chain of thought!

Enough talk, get to action already!

In this post we'll check how to set up a monitor and do a very basic task of checking if your website is up or not at regular intervals and reporting via email if it is down.

Don't worry, we'll cover more awesome things in a future post.

First things first, you need to sign in by visiting https://www.postman.com

Step 1: Go to a workspace

Well, all things in Postman reside in a workspace. So, the monitor we will be creating will reside in one of the workspaces you are a part of. Everyone, is a part of their own workspace(termed My Workspace) or you can create a new Workspace if you want to group your work separately.

Side note: We recently launched Public Workspaces and it is pretty cool, check it out in this blog post if you wanna know more.

Step 2: From the left sidebar, select collections and create one and add a request to it.

Step 3: Add details about your webpage.

Here, I will be sending a GET request to https://saranshdhingra.dev

Yes, this is a shameless attempt to advertise my portfolio website. I feel terrible, so if you could just visit the website, leave awesome feedback and read the rest of the article, I'll be on my way :D

In order to test it you can quickly send the request to see if everything works.

You should get a 200 status code response if your webpage is up and configured properly.

Note that in order to run the request from the web and not the app, you may need to select the Desktop Agent to avoid CORS issues. If your website is configured to allow all Cross Origin Requests then you may not need this. You can select the agent in the bottom right section of the page.

Step 4: Add a testing mechanism

We have set up how to send a request to our webpage, but how do we know if everything works perfectly. We want to automate the whole process after all!

Enter the Tests tab.

Just below the bar where you entered your webpage address you may see a lot of tabs, one of them will be the Tests tab. When selected it looks like this:

This is another tool in the Postman arsenal which I think is very powerful.

Think of this tab as a hook that runs after the request runs. So you can do all sorts of things with this, things like:

Getting the response body and parsing content.
Take some dynamic content and initiate another request based on that(we'll do this sometime later)
Check the status code of the response received(Bingo!)

So, in order to test if our website is working fine, every time we run our request, we'll be checking if the response code is equal to 200 or not.

This is how we do that:

pm.test("Check Status code of my website", function () {
    pm.response.to.have.status(200);
});

So, put this in the Tests tab and Run the request. You should see that your test passed(check it in the Test Results tab in the response section).

Try changing the status code in the test temporarily and running the request again to see how it behaves when the test fails.

Save the request, and now we can move to the monitors part of the tutorial

Step 5: Create a monitor for your collection

From the left sidebar, select Monitors and Create a Monitor.

Enter a meaningful name for your monitor.
Select the collection that we created earlier.
For now, you can keep the Version as CURRENT, and Environment as No Environment, we'll use them in future tutorials.
Select the desired frequency. For a normal, portfolio-like website an hourly frequency should suffice.

Please note that if your monitoring calls have a quota, you get 1000 monitoring calls free every month. You can check your current usage by going into the Resource Usage page.

The options should look something like this:

Additional Options:
You can set some additional options for more granular control over your requests.

For example, you can send the requests from multiple regions that ensures your website behaves similarly in different regions.

A very important option is to have an email sent to you whenever a Test fails on your monitor run.

So, if your website returns with a non 200 status code, you can get an email for the same.

We'll talk about cooler delivery methods in a future tutorial, but for now, let's select that.

Step 6: Run your monitor

You can either wait for your monitors to run at their designated time or Run them manually for testing. After running them, you see the records of individual instances when you had requested/scheduled the monitor to run.

By clicking on a specific bar, you can see more details about the requests and the test results.

Conclusion

So, we created a collection, set up a test that checks for a deciding criteria to know whether the website is up or not, and then automated the whole process to run at scheduled intervals.

I don't know about you, but I was very thrilled the first time I did this. I could imagine so many possibilities to achieve things that I needed to automate. Things that I knew how to achieve in code, but this was a whole other domain, no need to manage crons, no need to manage servers, and all from a tool that I use to test my APIs already.

Right now this is just a basic run through of a part of the product, but we'll get into more details, and we'll try to achieve something cool every time.

Stick with me, and you'll find Zen!
Actually no, I'm finding that myself, send me a link when you find it :P