Category Archives for Tutorials

How to Troubleshoot a Rule

Sep 20, 2016
by Dmitri Zimine

I set up a sensor to watch for a trigger (trigger represents an external event; sensor will fire a trigger-instance of the trigger type when the event is detected). I created a rule: if the trigger happens, and matches the criteria, it should fire an action. I see that event had happened. I expected the actions to fire. But it didn’t happen. Where did it break?

This is a long read, and may look complicated. But really, it’s just three debugging steps. And it’s long because I refuse to write briefly, drop bunch of hints on the way and get you distracted. But as they say in math, the thicker the math book the faster it reads. Brace yourself.

In the example below, I’ll be showing you how we debugged our Twitter automation that scans tweets for mentions and posts it to Slack. A pretty good way to keep track on who is trash talking about us! The debugging “runbook” is generic and applies to troubleshooting other rules just fine.

First, let’s look at the trigger chain and review how it works.


Cisco Spark integration for StackStorm

March 22, 2016
by Anthony Shaw of Dimension Data

I’m “pretty excited” to share some news, we’ve just finished integrating Cisco Spark into StackStorm, via our automation-bot, Hubot.
This means you can get all of the power of StackStorm chatops from within Cisco Spark rooms and collaboration experiences.

What is Cisco Spark?

Cisco Spark delivers cloud-based business communications that enables customers to message, meet and call anyone, whether it be on their mobile device, desktop or meeting room end-points.

What is StackStorm?

StackStorm is an event-driven automation platform that ties together every component of your environment. It’s commonly used for auto-remediation—including response to security events—and other cases such as complex deployments.

Configuring Cisco Spark

If you don’t already have a Cisco Spark account, you can sign up at

Once you have signed up, go to and sign in, then you should be able to generate a key


Improvements to ChatOps Pack Development User Story in ST2 1.4dev

February 15, 2016
by Jon Middleton, Optimisation Project Lead @ Pulsant Limited

In the post StackStorm QuickTip: ChatOps your pack dev workflow James Fryman gave a ChatOPS alias recipe to reduce the friction for deploying packs and then in the Random Thoughts section asked:

This action is tied directly to the packs.install. What about a workflow? Seems like that would be a better way to structure this.

This resonated with me as I had already started working on an internal pack that did just that, as I thought attempting to deploy a pack via an alias (and action) contained within the same pack would be madness (or just lead to interesting race conditions). In the last week, our Pull Request has been merged, documentation has been included in st2docs (link) for a workflow that fulfils the above random thought and should be released with 1.4.

So introducing packs.deploy, an action written in Mistral to handle the mapping of names for Git repositories to the information required to carry out the packs.install action.



StackStorm, Yammer, and cat pictures

February 8, 2016
by Edward Medvedev

Less than a week ago Microsoft announced a plan to activate Yammer — its corporate social network — for every customer with Office 365 subscription. Yammer will be seamlessly turned on for everyone with a business or education account over the next two months, which means more and more people will rely on it in their daily communication. Pretty exciting!

If you’re a long-time StackStorm user, chances are you already know what’s going to happen. After all, we only write articles with words like “pretty exciting” in them when we have something great to show, and this one is no exception: today we’re proud to announce ChatOps integration with Yammer for both Community and Enterprise editions of StackStorm!

If you’re new to ChatOps, it’s a chat-centric way to enable or extend DevOps — especially when based upon StackStorm. With the help of our powerful rules engine, workflows, and more, you can execute actions from your chat app of choice, keep it visible for your team, and grow your automation patterns over time. Naturally, our own blog has a lot of articles on the topic, like the recent On Force Multiplication and Event-driven Automation by James Fryman.


Watching the watcher: How to test and debug rules and trace what StackStorm does with triggers?

February 4. 2016
By Manas Kelshikar

We have always wanted StackStorm to be much more transparent than older run book automation systems so that users trust it – so they allow StackStorm to do more and more of the work such as quashing 2am pages via auto-remediation.

Recently we’ve added some capabilities that further increase StackStorm’s transparency.

This post focuses on a few features that help follow the breadcrumbs of an event-driven automation. It specifically provides ways to answer the questions –

  • Why does this rule not work?
  • What did StackStorm do with the event that it received?

We will put these question in context of a StackStorm Auto-remediation. The example for this blog will use StackStorm to auto-remediate an application that at times has poor API response times. The cast for this plot will be StackStorm as the guardian and protector, Sensu as the watcher and an application that must be brought back to the light when it starts erring in its ways.

We will specifically demonstrate the use of st2-rule-tester as well as what we call Trace Tags. As always in these kinds of “tutorial” blogs – we include the actual StackStorm content.


On Force Multiplication and Event Driven Automation

February 3, 2016
By James Fryman

Recently, I have found myself reflecting on the statement “Be a force multiplier”. This usually comes to mind when faced with some sort of burn-out: hearing in indirectly from a colleauge or friend, or experiencing it first hand. The intent is good and aligns well with some core tenants of DevOps. Force multiplication fits into the DevOps ethos by encouraging the need to cross-train and collaborate. By working together and sharing knowledge about respective domains (Development or Operations), team members gain empathy for each other. This in turn has a downstream effect of now enabling better collaboration around the repair/growth/operation/expansion of the delivery pipeline.

The only challenge that I have seen over and over again is that by the time that this idea of “force multiplication” is needed in a team, one or more major bottlenecks exist. These bottlenecks are often real and a result of an imbalance of resources. Servers arriving faster than there are resources to rack/stack/configure/turn-up. DBAs cannot handle the number of schema changes needed to be reviewed/tested/deployed. Developers must wait on a certain person or persons who have access to publish a package before it can “go live”. You probably have your own bottleneck that you see very clearly in your own mind.


Unifying disparate applications into the One System

January 29, 2016
By James Fryman

Originally published at

Let’s talk about a real problem that all of us have faced at one point or another: keeping track of a single thread of work across many disparate tools. Regardless of the specific industry a company operates in, as a company grows, back-office applications in support of the business begin to accumulate. Many knowledge based companies have some sort of communication tool, some sort of project tracker, and some support tracker. These are tools that aim at being more effective with daily business process. Conversations suffice until they do not, and tools are implemented as the need arises. Every tool that was added has purpose, solves a critical need, and made you and/or your team more productive.

At some point however, this changes. Discovery starts to become a major issue as usage patterns between different tools leaves solos of data. It becomes hard to correlate the different company pipelines that ultimately drive your business: the pipeline to care and communicate for customers, the pipeline to deliver new features, and the human interfaces involved in each. This is only intensified by team members that work on different project with different tools and people, you introduce team members from a timezone not your own, the sheer quantity of work… how many ways can you name how not just conversations are lost, but context


StackStorm QuickTip: ChatOps your pack dev workflow

by James Fryman

Happy Monday! In today’s StackStorm quick tip, we are going to show you a way to rapidly test and deploy packs. This technique pairs a StackStorm action, packs.install, and an Action-Alias that we will create to allow users to rapidly test and deploy new ChatOps commands for themselves.

Let’s just dive in!


StackStorm 1.2.0: the new ChatOps

December 8, 2015
by Edward Medvedev

ChatOps — a concept where a chat bot acts as a control plane for your operations — has always been a core part of StackStorm. It adds context to your actions, automates routine tasks nobody likes, helps team members communicate better and learn from each other, and sometimes it’s just plain fun. If you’re new to this, check out the DevOps Next Steps talk by James Fryman, and if you’ve been writing Eggdrop scripts in IRC since you were five but never used it in your daily operations, you might also get inspired from the ChatOps at GitHub talk by Jesse Newland.

Today, we’re all excited to introduce — as a part of our 1.2.0 release — a completely revamped ChatOps feature list. If you’re already using our Hubot integration to execute StackStorm actions from chat, stop doing whatever it is you’re doing and update! If not, it’s a good time to get started: ChatOps is the way of the future, now more than ever.


Build or Integrate Your Own Operational Dashboard w/ StackStorm (guest blog)

November 26, 2015
by Anthony Shaw of Dimension Data

This tutorial will show you how to leverage the power of the StackStorm API to expose your fantastic new workflows built using the Flow (available to Enterprise Edition uses) by following one of the blogs.

In our fictional scenario, we have built 2 complex workflows.

  1. Engage Tractor Beam, this workflow deploys some virtual machines to cloud, uses Hubot to notify the staff and then Puppet to drive the tractor beam.
  2. Open/Close loading bay doors, this workflow takes the desired state of the doors to drive another workflow.

We want to provide our technical operations team with a really simple UI where they can just click these buttons and we hide the magic behind the scenes.

Starting off

First off, this is a tutorial for ASP.NET 4.5, MVC 5 and WebAPI 2.0, the latest Microsoft Web Development toolkit.

If you want to use another stack, you can follow the patterns here to repeat in another language.

Opening up Visual Studio (here I am using 2013, 2015 would also work), select the ASP.NET Web Application template


When prompted, pick out the Single Page Application option, this will install a whole smorgasbord of web-development tools.READ MORE…