Show HN: A framework for building Slack bots in Python (github.com)

Anywhere you can run Python code basically. Sadly, with the decline of Heroku, I don't know of any places you can run Python code 24/7 for free.

Myself, I run Slack bots on AWS inside a Docker container on ECS (for $day_job) and inside a Docker container on my Synology for personal use.

I've been having fun using fly.io for a Telegram bot (listens on an HTTPS endpoint like a Slack bot, if I remember right). Has cost me $0 for my hobbyist bot that is only used by me.

I'm sure you can set up a raspi to deploy this with minimal running costs.

That is an interesting use case! The solution you propose, could work.

I've also been meaning to add support for webhooks as well, so you could trigger plugin functions by calling an HTTP endpoint. It's a small step from having messages on a queue and triggering webhooks from them.

I'd argue it's more about service or API integration.

People are willing to pay for solid solutions as long as you can add value

For instance, let's say PagerDuty did not have Slack integration. If you decide to build the glue that connects both you already have a ton of potential clients as they don't want to invest money themselves etc.

If you're trying to get a `worse than zulip` experience but really like threads then your only option is a paid bot called Smithy: https://smithy.app

So at least someone is making money from bots.

Slack workflows are pretty powerful, and there is definitely a gap in available actions (steps).

I'm working on a Slack bot that I'm hoping to monetize.

Sure. We used to have one that reported any error on any web app we had deployed.

You could use other types of reporting, of course, but that worked for us.

Any important information could be reported by the bot instead of wherever you normally find it.

It's a matter of what you build it to do.

Weekly reminder to fill out a report is nice. I would like Jenkins to send me a Slack message when my build fails.

Grafana alerts. GitHub PR requests. Jenkins builds. Surveys. Google Drive shares/comments. Dozens of other internal tooling integrations.

I can't imagine working without slack bots at this point.

Absolutely - couple examples that I've used in the last day or so: Github notifications (PR requests), Jira ticket updates (less useful), Figma notifications. Basically, Slack is aggregating the tool notifications into one place so I don't have to check email or each individual website.

I'd say ChatOps is a very legitimate use case. But I see your underlying point of bots frontloaded with a lot of logic.

We built a relay bit couple years ago. You can invite the bot into a private channel and then other users who are not part of the channel can use a form to send messages to that channel. The members of the Channel can then use the thread to answer.

Works really well and has the effect that inter-department communication don't always need to go through the department heads. This could, of course be abused for spam, but so far it worked well.

absolutely, we rely on them for a few things and it's very nice

We have a slackbot that announces when a new customer signs up for our service, with some info on them and links to view them in our admin dashboard + third-party apps. Also, once our app hears back from a third-party fraud-protection API, the slackbot will reply to the message with info on the result, and will also react to the announcement message with an appropriate emoji :) Helps out our support staff a bunch, reduces the surface area of the things they have to consistently look at.

It's very useful for us right now at our current scale. Should we start getting an inordinate amount of new signups everyday, we will have to start relying on other methods to understand the signups.

Yeah to me it's like the main thing that makes Slack useful. I have a ton of them hooked up. I'm in the events business so I have a feed of ticket sales, there's a feed from the sales department of opps opened, there's a feed from Confluence that tells me when someone edited one of our internal wiki pages, we have a shout-outs channel connected to our employee recognition platform that gets lots of attention when peer to peer praise comes in, we have one that's connected to our customer help chatbot on the homepage, which is expecially useful for responding to very timely questions about live events almost instantly (we get a lot of love for that), and a few others. I'm always thinking of new ones to write.

Having all the notifications just coming into one place is really good for "situational awareness" and I think it's one of Slack's main killer use cases.

Yup. We have a bot that the user slacks directly with a product code, and the bot will query our WMS and return the location it's in and how many are on hand. Why not just query the WMS directly? Because our WMS charges per user account, but not for API/developer accounts. This way we can allow office personnel that only need to look up something every couple of days without being charged for accounts that hardly ever get used.

(Grumpy senior engineer voice) "No."

Pretty much any github/jifa/wiki/servicenow/error log/etc type chat bot integration immediately become background noise as soon as your team exceeds a size of about 4 or your user base exceeds a number you can count on your hands.

Everyone slowly mutes or ignores notifications on those channels and goes about their day.

How much experience do you have with Slack? It sounds like you might have been burnt by spammy bots in the past?

Having used it for ~7 years at a bunch of companies, I can say with confidence that bots are a very core part of Slack’s value.

There certainly are spammy notifications that sound useful and turn out not to be, but it’s not hard to keep the signal to noise ratio high with a little effort.

I think you make a good point. I removed that word from the description.

It's not a naive question at all! The 2 biggest differences I can see:

- Errbot being chat service agnostic, also makes it feel a bit "non-native" for Slack. For example, you cannot say "@mybot deploy webapp to production", but you have to say "!mybot deploy webapp to production". slack-machine can work that way as well (with command prefixes like ! or %), but it also responds to actual mentions (@mybot). There are more differences like that, where Errbot tries to be agnostic of the chat service it's running against, but that also means it has to cater to the lowest common denominator in terms of integration with a chat service. slack-machine can for example add "reactions" to messages, which Errbot cannot.

- slack-machine seems more feature-rich. Errbot seems to be focused only on commands that are triggered by sending certain chat messages. slack-machine lets you listen to any type of event Slack emits. Examples could be: someone joins a channel, a reaction is added to a message, a message is pinned. slack-machine also has built-in scheduling to trigger plugin functions on a cron-like schedule (Errbot has something similar with pollers, but it's not as flexible as a cron schedule)

For me it was a clear design choice to focus only on Slack, so the bots you build with it feel as "integrated" as possible with Slack. You can really leverage all that the Slack API has to offer.