Table of contents

Re-run historical check notifications

This feature allows users to bulk ingest existing checks into a recently created Communication Channel. It is expected to be a one-time operation as newly discovered or updated checks will automatically be forwarded to Communication Channels through enabled automatic notifications.

Why re-run historical check notifications?

Using this feature will compliment the existing behavior for automatic notifications allowing users to re-run their historical checks (checks discovered prior to the creation of the communication channel) into their targeted communication channel. This is useful for users who may want to keep track of historical checks in their ticketing channel, whilst making use of the auto-resolve feature provided by the communication channels to resolve tickets.

API Endpoint:

Checks Replay.

Supported Communication Channels

  • Jira
  • ServiceNow
  • Zendesk
  • AWS SNS
  • Webhook

Important:

  • For ticketing channels (Jira, ServiceNow and Zendesk) re-running historical checks will not create duplicate tickets if a check is already associated with the ticketing channel.
  • For non-ticketing channels (AWS, SNS and Webhook) this will resend checks any time the endpoint is called.
  • If using an organisation-level communication channel, you will need to enter one account ID to re-run the historical check.
  • Only users with write access to the specified account (for which the communication setting is configured) can use this endpoint.
  • It may take several minutes for the check notifications to appear in your Communication Channel following a successful request.
  • Historical checks sent to your targeted communication channel will be filtered out based on the configured triggers for the communication channel.

User Scenario

  • It is highly recommended to have some triggers configured on your communication channel for details please visit here.

  • The API endpoint takes in two filters newerThanDays or olderThanDays, we recommend a time frame which fits closer to the creation or updated time of your communication channel. To get an idea on what checks you may want, you can configure the filters in the Browse All Checks section of the Conformity UI.

  • e.g. If my automatic notification communication channel was created 30 days ago from today. A filter of olderThanDays 30 will deliver historical checks prior to the creation of that communication channel.

Example

Let's assume you have on-boarded an AWS account and Conformity Bot has completed it's first scan, and you do not have a Jira Ticketing system setup.

Visiting Browse All Checks, you can see that your S3 bucket resource has created 2 failures. As a user you want to see these failure check notifications delivered to your Jira ticketing system.

To get all historical check notifications, you will create a new Jira ticketing communication channel and enable automatic notifications, and apply the following triggers:

  • Service: S3
  • Risk Level: Extreme, Very High and High
  • Tags: "staging" and "demo"

Using the API Endpoint with Postman:

Viewing that the Failed checks have been successfully imported into Jira.

After addressing those failures the automatic notifications on the Jira communication will resolve the 2 tickets that were created.