We're excited to announce a number of recent updates to CheckCentral!
We've updated nearly all the pages on CheckCentral to include pagination and filtering to ensure that your data is always easily available. As your organization grows, you will always have fast and simple access to your checks, groups, and more. You can also search for checks by name on your dashboard, to help you get to the information you need as fast as possible!
For organizations looking to automate the set up of their data, the CheckCentral API now supports create and delete endpoints to manage your checks, groups, and users. Access to these endpoints is restricted to API tokens granted the appropriate permissions. As well, we have also added authentication tokens tied to user accounts, which provide access through the API to only the data that that user is permitted to read or modify.
We've also made many other updates, such as an option to pre-sort newly created check groups in alphabetical order, improvements to PDF reports, the ability to configure Slack notifications for specific check groups, and notification emails now include the original message's attachments.
If you have feedback or questions about these updates or any aspect of CheckCentral, please let us know!
We're happy to announce that we're rolling out some updates to the CheckCentral mobile apps! The apps are updated with a new framework, and most of the changes are behind the scenes improvements. Here's the full list:
If you're not already using the CheckCentral mobile app, we encourage you to try it out. As always, if you have any feedback, we'd love to hear from you!
The CheckCentral API provides an endpoint for adding users programmatically. All of the configuration options are available through the API, detailed below. To add a new user through the API, you will require an API token for your organization with Read/Write access. Organization administrators can create tokens through the API portal on your dashboard.
The endpoint is located at https://api.checkcentral.cc/createUser/?apiToken=APITOKEN where the APITOKEN placeholder is replaced with your valid token. The request must be made with the Content-Type header set to application/json. The body of the request should contain the properties below to configure the new user's settings. Any properties not passed will be set to their default value.
For example, to add a new user you could send the following json in the body of the request:
The user data must include an email property as well as an accessLevel at minimum.
The complete list of possible properties for user creation are as follows:
| Parameter | Type/Allowed Values | Default |
|---|---|---|
|
The email address of the new user. The |
String | |
|
The access level to grant the new user. The |
One of:
|
|
|
The name for the new user. If the |
String | |
|
Pass the sendWelcomeEmail flag to have CheckCentral send an introductory email to the new user. |
Boolean | false |
|
Pass an array of user group IDs to add the user to those user groups. User group IDs can be retrieved with the getUserGroups API endpoint. |
An array containing user group IDs. |
[] |
|
Pass an array of json objects to configure which services CheckCentral should use to communicate with the user. |
Array[NotificationConfig] | [] |
| Parameter | Type/Allowed Values | Default |
|---|---|---|
|
Pass the type of notification to configure. The |
One of:
|
|
|
The list of services that CheckCentral should use to alert the user about the configured type of notification. Any services not included in the array will be disabled for the notification type. |
Any of:
|
[] |
The CheckCentral API provides an endpoint for creating checks programmatically. All of the configuration options are available through the API, detailed below. To create a new check through the API, you will require an API token for your organization with Read/Write access. Organization administrators can create tokens through the API portal on your dashboard.
The endpoint is located at https://api.checkcentral.cc/createCheck/?apiToken=APITOKEN where the APITOKEN placeholder is replaced with your valid token. The request must be made with the Content-Type header set to application/json. The body of the request should contain as many of the properties listed below as required to define the check. Any properties not passed will be set to their default value.
For example, to create a new check that:
you would send the following json in the body of the request:
{
"name": "An API Check",
"email_alias": "apicheck",
"interval_type": "hour",
"interval_value": 2,
"active_days": [
"mon",
"tue",
"wed",
"thu",
"fri"
],
"success_conditions": {
"required_conditions": "any",
"conditions": [
{
"message_field": "subject",
"matches": "exactly",
"value": "Message Success"
},
{
"message_field": "body",
"matches": "contains",
"value": "No Errors Reported"
}
]
}
}The check data must include a name property, as well as at least one of email_alias and matching_conditions to allow the check to be matched against incoming messages.
The complete list of possible properties for check configuration are as follows:
| Parameter | Type/Allowed Values | Default |
|---|---|---|
|
The name for the new check. The |
String | |
|
The plus alias for the check. This will be used to generate the custom email address for the Check along with your organization account name: account_name+email_alias@mycheckcentral.cc. At least one of the |
String | |
|
The rules that will be used to match incoming messages. See the definition of a ConditionGroup below. At least one of the | ConditionGroup | {} |
|
The ID of the group to assign this check. IDs may be retrieved from the |
String | |
|
A text description for the check. |
String | |
|
The interval unit CheckCentral will use to calculate the expected arrival time of incoming messages |
One of:
|
day |
|
The number of interval units (see above) used when calculating the expected arrival of incoming messages. |
Integer | 1 |
|
How many minutes after the interval has elapsed CheckCentral will wait before flagging the check as failed. |
Integer | 30 |
|
An optional time of day when messages will begin to be received. |
String | 00:00 |
|
An optional time of day when messages will cease to be received. |
String | 00:00 |
|
Pass an array of days to indicate which days the check should expect to receive messages. |
An array containing either
|
[ "all" ] |
|
Pass an array of personal notification services to configure the check to send alerts via those services. |
An array containing any of:
|
[] |
|
Pass an array of organization notification channel IDs to configure the check to send alerts via those services. IDs may be retrieved from the |
Array[String] |
[] |
|
Pass an array of organization external ticketing system IDs to configure the check to create and update tickets via those services. IDs may be retrieved from the |
Array[String] |
[] |
|
Checks with this flag will send an alert when they are restored to a success state by an incoming message. |
Bool | true |
|
Checks with this flag set to false will only send alerts during the time window and active days configured above. |
Bool | true |
|
This parameter controls when CheckCentral will send alerts about repeated failure or warning messages. |
One of:
|
always |
|
If notify_consecutive_alerts is set to either after_n or every_nth, this parameter configures how many consecutive failures or consecutive warnings will trigger alerts. |
Integer | 1 |
|
The number of minutes this check will wait to send alerts about failures. If the check is returned to successful status before this period elapses, any pending alerts will be cancelled. |
Integer | 0 |
|
The default status for incoming messages that don't match against any of the conditions below. |
One of:
|
failure |
|
The rules that determine whether incoming messages will be set to success. See the definition of a ConditionGroup below. |
ConditionGroup | {} |
|
The rules that determine whether incoming messages will be set to warning. See the definition of a ConditionGroup below. |
ConditionGroup | {} |
|
The rules that determine whether incoming messages will be set to failure. See the definition of a ConditionGroup below. |
ConditionGroup | {} |
| Parameter | Type/Allowed Values | Default |
|---|---|---|
|
This parameter controls whether incoming messages must meet any or all of the conditions defined below to be considered a match. |
One of:
|
"all" |
|
If this flag is set, all of the conditions defined in this group will treat multiple whitespace characters as a single space. |
Bool | false |
|
The list of conditions for this ConditionGroup to match messages against. See the definition of a Condition below. |
Array[Condition] | [] |
| Parameter | Type/Allowed Values | Default |
|---|---|---|
|
Which part of the incoming message will be examined for this condition. |
One of:
|
subject |
|
What matching rule this condition will use. |
One of:
|
contains |
|
The value to use with the above matching rule and message component. |
String |
Website Certificate Expiry Check
SUCCESS
WARN
