Introducing sls-dev-tools — Improving the Serverless developer experience.

Ben Ellerby
Dec 16, 2019 · 4 min read

Having led several teams running 100% Serverless infrastructures in production there was a clear area of the Serverless developer experience that could be improved.

In short, it’s the feedback loop of deploying a function code change and getting visibility on if it’s been called, what the metrics are looking like and having quick access to any logs.

Taking inspiration from the frontend developer experience we wanted to have an equivalent to chrome dev tools, but for our backend Serverless functions.

I’m very pleased to announce the early-stage release of Serverless Dev Tools (sls-dev-tools). It’s completely opensource, solves a few core pain points for our team — and has a lot of features and improvements that we can build out in an opensource community.

What is sls-dev-tools trying to do?

It’s trying to allow developers to get feedback and metrics on their function deployments without opening the cloud provider web console (in our case AWS) — staying in their IDE and terminal.

What sls-dev-tools isn’t trying to do?

sls-dev-tools is not trying to provide complete Serverless Observability in your staging, UAT or production environments. It is not a distributed logging visibility too, it’s not an alert platform and it’s not a tracing tool.
There are several amazing companies providing Serverless Observability (e.g Thundra, Lumigo or Epsagon).

sls-dev-tools is in short, Chrome Dev Tools for the Serverless World.

How to get started?

Well, if you’re using AWS Lambda functions, you can use this tool today — otherwise, you’ll have to wait or open a PR or Issue to support other cloud providers.

It doesn’t matter what framework, language or IaC you’re using, the tool uses CloudWatch Logs to generate all the metrics it needs.


  • npm install -g sls-dev-tools


As sls-dev-tools is based off the AWS SDK authentication will happen automatically if your credentials are set-up within environment variables or in the ~/.aws/credentials directory.


  • sls-dev-tools -n {YOUR_STACK_NAME} -r {YOUR_REGION} [-t {START_TIME}] [-p {PERIOD}]
  • The start time defines when you want your graphs to start from, and the date format for the start time is YYYY-MM-DD/HH:mm
  • The period defines the size of the buckets in seconds. This means if you give a period of 3600, the line graph will group the invocations and errors into 1h chunks, and the bar chart will show the average response time over the hour for the last 6 hours during which invocations were made.
  • To get the stack name, log on to AWS CloudFormation and it is shown in the overview section of stack info. It may not be what you expected e.g. it might have -dev on the end, so worth checking if the dev tools are not working.
  • The region is the AWS region, for example, us-east-1.
-V, --version output the version number
-n, --stack-name <stackName> AWS stack name
-r, --region <region> AWS region
-t, --start-time <startTime> when to start from
-p, --period <period> precision of graphs, in seconds
-h, --help
  • Choose a function with the arrow keys, and press enter to see the metrics for that function.
  • If you get an AccessDenied error in which case you must add the GetMetricData permission from CloudWatch in the IAM console on AWS.
  • If you’re not seeing any data in the graphs, try changing your start date to make sure you have had invocations since then.
  • The line graph shows the number of invocations and errors that occurred within the time period.
  • The bar chart shows the average response time of the invocations within the last 6 time periods that had some invocations.

We need your help!

If you find this tool useful or have any feedback please get in touch via GitHub issues or Twitter

We are also actively looking for contributors and will be available to help you find good first issues, code review and assistance on developing out any new functionality.


Serverless Transformation

Tools, techniques, and case studies of using serverless to release fast and scale optimally.

Ben Ellerby

Written by

VP Engineering, working with startups to launch MVP’s and large corporates to deliver in startup speed. Currently changing the way I build with Serverless.

Serverless Transformation

Tools, techniques, and case studies of using serverless to release fast and scale optimally.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade