> For the complete documentation index, see [llms.txt](https://docs.adsecure.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adsecure.com/docs/guides/custom-alert-rules.md). # Managing Custom Alert Rules This guide is going to help you to customize how the AdSecure's [crawler](/docs/development/concepts.md#crawler) is going to determine if a [violation](/docs/development/concepts.md#violation) should be considered or not as an [alert](/docs/development/concepts.md#alert). > If you're not familiar with GraphQL, please have a look at its [dedicated section](/docs/graphql/overview.md) in this documentation. The AdSecure's [crawler](/docs/development/concepts.md#crawler) is configured to inform you about the [violations](/docs/development/concepts.md#violation) found during an analysis by comparing its results with the international standards. That said, you might want to customize the way these [violations](/docs/development/concepts.md#violation) are reported. At AdSecure we call these custom settings [Alert Rules](/docs/development/concepts.md#alert-rule) where an [alert](/docs/development/concepts.md#alert) is a [violation](/docs/development/concepts.md#violation) that you consider as critical. Let's consider that for example, a *Landing Page Error* is critical on your network and should be considered as an [alert](/docs/development/concepts.md#alert). To do so, we need to create a new [alert rule](/docs/development/concepts.md#alert-rule) where this specific detection is going to be alerted. In the same way as for the creation of a new analysis, creating an alert rule is associated with a mutation in GraphQL. > By default, all the [violations](/docs/development/concepts.md#violation) are not considered as [alerts](/docs/development/concepts.md#alert). The entire list of [`Violation`](/docs/detections.md) is available and can be retrieved by running the following query: > > ``` > query { > violations(first: 50) { > nodes { > login > } > } > } > ``` ## Prerequisites Before starting this guide, please be sure that you're ready to use our service by following the steps illustrated in the [Quickstart](/docs/development/quickstart.md) section. ## Simple case For creating a new alert rule we need to send a payload that contains the following fields: * The `name` that's going to help us to easily remember the role of this alert rule. This value is also going to be used to generate the alert rule's login. * An array of violations' `login` that we want to alert - as values of the `violations` field. **Query** ```bash mutation { createAlertRule(input: { name: "Landing page error", violations: [ "landing-page-error" ] }) { login name violations { login name } } } ``` **Response** ```json { "data": { "createAlertRule": { "login": "landing_page_error", "name": "landing page error", "violations": [ { "login": "landing-page-error", "name": "Landing Page Error" } ] } } } ``` We can now use this alert rule when we create a new analysis. To do so, we need to set the alert rule's login as additional parameter to the example illustated in the [First Analysis](/docs/guides/first-analysis.md) guide and we ask the API to return us an additional field `alertViolations`: **Query** ```bash mutation { createAnalysis(input: { content: "https://examples.adsecure.com/404", alertRule: "landing_page_error", }) { id alertViolations } } ``` **Response** ```json { "data": { "createAnalysis": { "id": "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=", "alertViolations": ["landing-page-error"] } } } ``` That's it! The analysis is going to be processed as usual, but if your content is not accessible at that time it won't be considered as an alert and you won't be notified about it! If we then fetch the analysis you can see that event if a *Landing Page Error* was detected by our crawler and reported as a violation, it will be considered as an alert: **Query** ```bash query getAnalysis { analysis(id: "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=") { id content status alert violation violations alertViolations } } ``` **Response** ```json { "data": { "analysis": { "id": "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=", "content": "https://examples.adsecure.com/404", "status": "DONE", "alert": true, "violation": true, "violations": ["landing-page-error"], "alertViolations": ["landing-page-error"] } } } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.adsecure.com/docs/guides/custom-alert-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.