NEW: Get a FREE 30-day trial of OpsLevel. Sign up here.

Table of Contents
Getting Started
Ownership
Single Sign On
User Management
Service Maturity
Service Creation
Campaigns
Custom Actions
Checks
Insights
Integrations
Self Hosted
Roles

Admins can create a new Custom Action by navigating to the Actions page and clicking on the “New Action” button.

"New Action" button

Basic Details

An Action's basic details provides context to users about who manages the action and how it should be used.

Basic detail form inputs.
Description
Name The name of the action. Users will see this when invoking the action
Owner The team is responsible for maintaining this action. Users invoking an action will be directed to this team in case of error.
Description Additional information about what this action does or how it works. Users will see this information before invoking the action.
Mark as draft Draft actions are only available to admin users. This option lets you test actions before making them available to other users in your OpsLevel account.

Default: true

Action Context 

Actions can be scoped to apply to only a subset of the services in your OpsLevel account.  For example, an action to provision infrastructure could be set to only apply to services with a tag of prod_enabled: true.

Actions can also be limited to certain sets of users and can have custom input parameters defined.

An Action’s context is where all of this configuration is managed.

Action context form inputs.
Description
Access control Control who has access to this action. Possible values are:
  • Everyone – Available to all users.
  • Service owners – Available only to members of the team defined by the “owner” field.
  • Admins only – Available only to admin users.
Filter This action will be available to services matching this filter.

Check out the filter docs for more info.

Default: All Services
Require form submission Enables the “input” field allowing you define the action’s user input fields.

Default: false
Input Define the input fields that will be presented to the user. These allow users to provide contextual information to the action being invoked.

Inputs are defined using YAML markup, see Configuring Manual Inputs for more information.

Action Rules

An Action's rules define the webhook URL for the action and any information included with the HTTP request.

See the end-to-end example for a sample of Action Rules, including parameterizing a URL with Liquid.

Action rules form inputs.
Description
HTTP method The HTTP method that will be used when the action is invoked.

Supported values: GET, POST, PATCH, PUT and DELETE.

Default: POST
Webhook URL* The destination of the HTTP request.
Headers* The JSON representation of the headers to be included in the HTTP request.
Payload* The body of the HTTP request.
* These fields can dynamically insert information from the action’s context via liquid templating.

See the Action Context Schema for the list of fields available and this example for how to use them.

Response Details

An Action’s response details control what message is displayed to the invoking user after it has finished.

Response details form inputs.
Description
Response Message The message displayed to the invoking user after the HTTP request for the action has completed. The message can be conditionally changed based on the fields in the response via liquid templating.

This field can also dynamically insert information from the action’s context into the message body.

See the Action Context Schema for the list of fields available and this example of how to use them.