Enable developer self-service with Actions in OpsLevel

With Actions from OpsLevel, developers can now safely self-serve to complete core operational tasks like:

• Create a new S3 bucket
• Resize infrastructure
• Request time-limited escalated tokens/permissions
• Provision a new Kafka topic
• Send a structured Slack message
• Trigger an incident
• Open or merge a PR
• File a new issue or ticket
• Lock or unlock deploy pipelines—step-by-step example here
• Rollback the last deploy
• Kickoff any pipeline
• Call any serverless function
• ...and much more.

There are endless ways to use Actions to streamline operations, let developers self-serve, and improve your developer experience. 

With Actions you can create new actions to unblock your developers while ensuring that things are done in line with best practices. More automation, fewer bottlenecks; everyone wins.

Why Actions?

Even though developers are accountable for more operational work than ever before, they often don’t have the necessary tools or permissions. They end up dependent on (or blocked by) platform engineering teams.

While platform teams are buried under tactical tickets or requests, developers lose autonomy and feel stuck. It’s a poor experience for both groups and can make an entire organization less efficient.

With Actions available in the OpsLevel developer portal, service ownership isn't such a burden and tasks like rolling back the last deploy or provisioning generic infrastructure are self-serve, at the push of a button.

Actions are a win for everyone in your engineering organization.

Developers

Work faster and more independently when "day 2" operational work doesn’t get stuck in a platform team’s queue.

Platform Engineers

Spend less time reacting to inbound tactical requests and more time on proactive, strategic work

Engineering Leaders

Provide a better developer experience (reduced friction to get stuff done, more time for strategic, creative work) and still get the benefits of a structured process (single integration point, reduced risk of human error, audit trail).

How do Actions work?

Create and configure

Actions are built on top of outbound webhooks from OpsLevel. Only OpsLevel admin users can create and configure (via our UI, API or Terraform provider) the webhook actions.

Once they’ve been created, the actions will appear on relevant service detail pages, based on the filter applied to the action. Admins can also control who is able to trigger an action: only other admins, service owners, or any OpsLevel user.

Since they’re triggered from your OpsLevel catalog, all actions are context-aware; metadata about each service is available to be used to scope actions to a service or repository or include relevant details in the payload–no need for creating duplicate, hardcoded actions.

Actions also support multiple types of user inputs—and validation on those inputs–so developers can supply the necessary names, descriptions, or justification that go along with actions and platform teams can ensure that actions run with valid parameters and resources are named or tagged appropriately.

For more details on how to configure your first action, review our docs here. 

Closing the loop

When OpsLevel receives a response to the merged HTTP request, the user who triggered the action receives a response message using the context from the triggered action and the HTTP response that was received.

Admins can fully customize these messages and include conditional logic based on the HTTP response. This way, it’s clear what a user should do after triggering an action in order to verify and access a new resource or continue a broader workflow—no loose ends.

For admins, OpsLevel provides a filterable execution history where they can review in detail all the actions that have been triggered in the OpsLevel instance.

‍

Ready to get started with the OpsLevel developer portal, create your first Action, and unlock self-service for developers? Sign up for a free trial and get access to the full OpsLevel platform today.