Required, Reserved and Optional Attributes | All Quiet Payload Mapping Guide

Hi there and thanks for joining. My name is Peer and today we talk about payload mapping at All Quiet, how to transform an incoming payload to an All Quiet incident using our required reserved and optional attributes to enrich an incident with all the information that your team needs. Now before we look at the mapping, remember that All Quiet can handle almost any HTTP request. As demonstrated before, you can simply take your integration’s webhook URL and paste it into your browser. By hitting enter, I've sent a simple HTTP request that, as you can see, created an incident. However, most of the tools you will be using will be sending much richer data. So, for a more realistic example, let's use a cURL command to send a POST request. You can simply test this command via your terminal. I've prepared a command that includes an alert name, a status, a description, a severity level, and even a graph URL. So, let's trigger this command and see that a new incident was created in All Quiet. We can use this command to take a deeper look into our payload mapping and our attributes and how they work. To do that, select the payload in the payload mapping and look into it. As you can see, the JSON body includes all the attributes that we just described. Now, let's look at the payload mapping. First, we're going to look at our required attributes. The first one is the status. It's kind of the on and off switch of your incidents. Every tool has its own vocabulary. One might send "triggered", one might send "firing" for "Open" incidents, another say "healthy" if an incident is "Resolved". All Quiet streamlines this complexity by requiring you to map these various terms to either "Open" or "Resolved". This ensures our incident lifecycle remains consistent no matter where the data comes from. Now, let's look at the mapping for the Status attribute and see how we can extract the JSON body's "alert_status" and map it to an "Open" All Quiet incident. As you can see right now, the mapping is pretty simple. It simply says every incident is statically "Open". We can click on that mapping step and change the mapping type from "Static" to "JSONPath". This will allow us to look at the latest payload that we just selected and extract the value of the attribute "alert_status" which is "Firing". Now as you can see "Firing" of course is not "Open" or "Resolved". So we need to map "Firing" against "Open" or "Resolved" in a way that works for All Quiet. So we can add a second mapping step which is the type "Map". And now we can add mappings from "Firing" which is the input to "Open" or "Resolved". Of course I want to map "Firing" against "Open", but I might want to map "Healthy" against "Resolved" because I know that an incident that is resolved will send a payload that includes "healthy". I can even add a fallback. For example, I know that it will always be "Healthy" if it's resolved. So if anything else is being sent, I want to make sure I receive an "Open" payload to not miss anything and to create a new incident as a result. Saving this will also repair my incident preview here on the bottom of the page. And you can see that "Firing" in this case is mapped to "Open". Now the second required attribute in All Quiet is "Severity". Severity is just like status, something that differs across different tools. Some call it "P1" if it's very important and urgent. Other tools will call it "critical" or just simply "emergency". In All Quiet, these must be streamlined into three standards: "Minor", "Warning", or "Critical". Probably this is the most important part of your mapping because it in the end decides which incidents will be triggering which notification and escalation policies. So think wisely here. Now we have the reserved attributes that control incident logic but are not required. We still highly recommend them and the names are reserved. Let's start with the "CorrelationID". The "CorrelationID" is kind of the unique fingerprint of an alert. It is used to identify and correlate incidents. If you send multiple payloads with the same "CorrelationID", All Quiet knows they belong together and won't create incident duplicates. So if the same incident ID is sent for different payloads, we will update the incident instead. Or for example, if a payload would include "Healthy" in the alert_status field, we would resolve the incident. Second, there's the "Title". This is the headline of your incident and the first thing people see. If you leave this blank, we will default it to the integration's name. Third, "Discard". This is pretty powerful and a good gatekeeper. By mapping a condition to "Discard" and setting it to "true", you tell All Quiet to ignore the payload entirely. So in this case, we say if the HTTP method, the request method, is HEAD, we will "Discard" the incident and we will not discard it, meaning we will create the incident, if it's a different method. To make your incidents more visual and organized, we provide optional keys on top which you can see in these columns here. "Grouping" - whenever you enable this, matching values for an attribute will group incidents into one and reduce noise. We will cover "Grouping" in a different video. "Hidden" - by activating "Hidden", you can hide incident attributes on overviews in the app or the web app or also in messages to tools like Slack. To give you an example, the graph is currently only a link. We might not want to have it on the preview, so we can simply set it as "Hidden". And then you can also see in the preview here that you don't see it on the incident overviews but only in the details. Finally, you can add as many attributes as you like. So you could for example say I want a new attribute called "New Attribute". And then you can set anything for this attribute based on the mapping types we just showed. Like for example JSONPath or you could add a regex or simply a static value and add further mapping steps. We already added a custom attribute called "Graph", and this is an attribute that we want to use to show you the third of our optional keys - "Image". The graph links to an image that we want to include in the incident. So if we know it's an image, we can just simply select "Image" → "true". And you can already see in the preview that we have a graph that shows the load of our systems, which is really nice and which can be included in all All Quiet incidents. This is everything about the attributes in All Quiet. Next video we will have a deeper look into payload mapping. Thank you so much for watching. Make sure to take a look at the other videos of our YouTube channel. Also, you might want to check out docs.allquiet.app for more helpful content.