Monitoring Your Home Internet Connection Using Slack, Revisited

Originally published May 4, 2019. Substantially revised July 2026.

The original version of this article was a step-by-step tutorial built around Slack’s Real Time Messaging API. That API and the accompanying Slack setup are now legacy, so I have removed the obsolete instructions. This revision preserves the useful architecture, explains what changed and describes what I would build today.

In 2019 I wanted a notification when the internet connection at home disappeared.

That sounds simple until you notice a small trap: if the Raspberry Pi or Kubernetes cluster at home loses its internet connection, it cannot reliably send a Slack message saying that the internet is down. The message has to come from somewhere else.

That was the useful idea behind my original setup. Slack delivered the notifications, but the important part was the observer. A small process outside my home network watched a small process inside it.

The Original Experiment

The original version used Slack bot presence as its signal:

• Nilbot ran on a Raspberry Pi, a home Kubernetes cluster or another always-on machine at home.
• It maintained a WebSocket connection to Slack through the RTM API.
• Spybot ran on a small Google Compute Engine VM outside the home network.
• Spybot watched Nilbot’s Slack presence and sent a message when Nilbot changed from active to away.

It was a neat hack in 2019. It needed no inbound port forwarding, reused Slack’s mobile notifications and made the external observer visible in a tool I already had open.

I would not build it that way from scratch today.

The Part Worth Keeping

The durable lesson is simple: monitor a network from outside that network.

A monitor inside the home network can collect useful local information, but it shares the same failure domain as the connection it is watching. When the failure is “no route to the outside world”, it may detect the problem and still be unable to tell you about it.

A current design still needs three parts: something at home that proves it is alive, something outside the home network that notices when the proof stops arriving and an outside component that sends the notification.

The proof might be a regular heartbeat, an active probe of a deliberately exposed endpoint, the state of an existing VPN tunnel or an agent connection to a monitoring service. The notification might arrive through Slack, email, SMS or another channel.

Slack is still a reasonable destination for an alert. I would use it as the place where the result is reported, not as the mechanism used to infer whether the home connection is alive.

Why the Old Tutorial Had to Go

The original instructions described a specific Slack app interface, tokens, Docker images, a Helm 2 installation and a Google Cloud VM configuration. Leaving those steps in place would make the page look like a current tutorial even with a warning at the top.

Several important assumptions have changed.

Slack RTM is now a legacy API

The old design depends on Slack’s Real Time Messaging API. Slack now treats RTM as legacy. Newer granular-permission apps cannot use it, and Slack directs most new event-driven apps toward the Events API or Socket Mode.

The Events API is not a drop-in replacement for this particular trick. Slack’s presence documentation says presence-related events cannot currently be tracked through the Events API. Recreating the old design would therefore mean building on a legacy API.

That makes the 2019 Slack screenshots and configuration steps historical records, not a responsible starting point for a new installation.

Presence never meant only one thing

Nilbot becoming away did not prove that the ISP connection was down. It proved that Slack no longer saw Nilbot as active.

The cause could have been a home internet outage, but it could also have been a crashed Raspberry Pi or Kubernetes node, a stopped process, an invalid Slack token, a Slack service problem or a broken WebSocket connection.

That signal was useful for the original goal, but it combined several failure modes. The honest name for it was a home Slack connection monitor, not a precise ISP diagnostic.

The deployment details became historical

The original Google Cloud machine type, Container-Optimized OS version and Helm command captured one working setup in 2019. Cloud free tiers, operating-system images and Kubernetes tooling have all moved since then.

The Nilbot and Spybot source repositories remain useful as records of the experiment, but the application images were built in 2019. I would not direct readers to deploy them now without reviewing the source, dependencies, permissions and container build.

Keeping the old commands would add archaeological detail without helping someone build a dependable monitor today. I have therefore removed them rather than translating each obsolete instruction into a superficially current equivalent.

What I Would Build Today

For a new setup, I would choose a heartbeat design.

A small process inside the home network periodically contacts a service outside it. The outside service records when it last heard from home. After an appropriate number of missed heartbeats, it sends an outage alert. When heartbeats resume, it sends a recovery message.

The outside component could be a managed heartbeat monitor, a general monitoring service, a cloud function or a small service on a VPS. Whatever you choose, it should tolerate an occasional delayed request, keep a record of the last heartbeat and send both outage and recovery notifications. It should also suppress repeated messages during one outage and make its own failures visible.

For Slack delivery, use a currently supported integration offered by the monitoring service or a Slack incoming webhook. Slack documents incoming webhooks as a current way for an app to post messages to a channel. Treat the webhook URL as a secret because anyone holding it may be able to post through it.

I am deliberately not including a new sequence of product-specific setup steps here. The best instructions depend on whether you want a managed service or your own outside observer, and an untested miniature tutorial would age in exactly the same way as the one it replaced.

An active external probe can also work, but it requires something at home to be reachable. Do not expose a router, dashboard or administrative service merely to give the monitor an endpoint. If you already operate a suitable public endpoint or tunnel, probing it may be sensible. Otherwise, an outbound heartbeat is usually the smaller and safer design.

What an Alert Actually Tells You

A missed heartbeat is still a symptom rather than a complete diagnosis. The ISP connection may have failed, but so might the home router, the monitored machine, the heartbeat process, DNS, an intermediate route or the outside monitoring service.

That is usually enough to answer the first practical question: can the home system still reach the outside observer? More detailed diagnosis can happen after the alert.

If distinguishing an ISP outage from a local machine failure matters, use more than one signal. For example, run heartbeats from two independent devices, combine a heartbeat with router telemetry or compare the result with an external probe. Each extra signal adds operational work, so add it only when the distinction changes what you will do.

The Lesson That Survived

The original design was not wrong because its Slack API aged. It solved the right problem with tools that were convenient at the time.

Two bots quietly watching each other had some charm, but Slack presence was incidental. Observer placement was the real design decision.

The modern version is more direct. Monitor from outside the network that might fail, use an explicit heartbeat or a safe external probe and treat a missed signal as evidence rather than a complete diagnosis. Deliver the alert through a supported Slack integration, then send another notification when the connection recovers.

That is easier to maintain and easier to explain when the internet is down and the phone finally buzzes.