marbot, our submission to the AWS Serverless Chatbot Competition

Andreas Wittig – 30 Sep 2016

Three things Michael and I love to do most: prototyping innovative products, playing around with the latest technology and learning new things. That is why we decided to take part in the AWS Serverless Chatbot Competition. We’d like to introduce marbot, our chatbot, to you and share the backstory of its creation.



The AWS Serverless Chatbot Competition started on August 10 with the following conditions:

Create a working bot for Slack that runs on AWS Lambda. Applications must use AWS Lambda and Amazon API Gateway for bot logic and integration. Applications cannot be hosted on any other hosting platform. Use of Slack APIs, such as the Slack Events API, is encouraged but not required.

On top of that AWS provided the following submission recommendations:

  • Integrate Slack APIs, such as the Slack Events API
  • Utilize additional AWS services
  • Submit application to the Slack App Directory
  • Showcase natural language processing of chat conversations

But what to build?


Working as DevOps engineers in various teams we have always been looking for a tool to share on-call duty among many shoulders without the need for organizational overhead. We came up with the idea of building a chatbot to combine Amazon CloudWatch with Slack.

We defined the following feature set as minimum viable product:

  • Receiving alerts from Amazon CloudWatch via Amazon SNS
  • Escalating alerts if a team member isn’t acknowledging within 5 minutes
  • Managing alerts by accepting, passing or closing them
  • Analyzing alerts in a daily summary
  • Grouping alerts with a dedicated alarm gateway for each channel

How did we implement the chatbot?


The following figure is showing an architectural overview of marbot. We used a bunch of services and APIs.

Serverless Architecture of marbot

The diagram was created with Cloudcraft - Visualize your cloud architecture like a pro.

Are you interested in the details? Read on!


The Serverless Framework simplified the provisioning and deployment of all the resources needed to setup the environment.

AWS Lambda and Amazon API Gateway

We used the API Gateway and Lambda for creating our backend and implemented endpoints for incoming events from Slack as well as from CloudWatch via SNS.

Amazon DynamoDB

DynamoDB is our favorite NoSQL database on AWS. marbot is storing channel endpoints, alarms together with their escalation state, and Slack authentication credentials.

Amazon Kinesis Streams and Amazon Kinesis Analytics

To provide daily team statistics marbot is analyzing event data with the help of Kinesis Streams and Kinesis Analytics. The statistics generated by Kinesis Analytics include the number of received alarms, time to acknowledge, time to close and much more.

Amazon SQS

marbot needs to escalate alarms to the next level if a team member is not responding. We implemented the needed scalable timer with SQS and Lambda. The solution is similar to what I’ve already described in Integrate SQS and Lambda: serverless architecture for asynchronous workloads.

Amazon SNS and AWS CloudWatch

All you have to do as a marbot user is to send your CloudWatch alarms to an SNS topic. The SNS topic is then forwarding the alarm to the marbot backend.

No EC2 instances needed. The whole architecture relies on highly available and scalable AWS services.


marbot is accessible to the public and free to use. More and more teams are using marbot to connect Amazon CloudWatch and Slack to spread alerts among their team members.

Try marbot now! We are looking forward to your feedback.

Andreas Wittig

Andreas Wittig

I’ve been building on AWS since 2012 together with my brother Michael. We are sharing our insights into all things AWS on cloudonaut and have written the book AWS in Action. Besides that, we’re currently working on bucketAV,HyperEnv for GitHub Actions, and marbot.

Here are the contact options for feedback and questions.