stts is a menubar app that watches cloud status pages and tells you when one goes down

A menubar item rather than a window, and that is the whole design

stts is described as a macOS app for monitoring the status of cloud services, and the interaction model is stated in one sentence. With a click of the menubar icon, you can see the status of your favorite services, and you can also be notified when a service goes down or gets restored.

There is no main window, no dashboard and no settings screen mentioned in the README. The screenshot is a narrow panel 218 pixels wide, which is the size of a menu bar popover, and the described behaviour is a click to open the status list and a single click to reach the status page.

The design goal is stated outright: stts is designed to be unobtrusive, only giving you the information you need and allowing you to access the status page with a single click. That is worth taking seriously as a design constraint, because the failure mode for status checkers is being one more icon that grows a notification habit. An app that only tells you when something is broken, and is silent otherwise, is asking for less of your attention.

The notification behaviour has two halves, down and restored. Both matter and they are different products. A down notification tells you to stop depending on the service. A restored notification tells you the outage is over, which is the signal you would otherwise have to go looking for, and which is genuinely useful for the case where you paused work waiting on a provider.

The primary language is Swift, with a Swift 5 badge in the README title. The licence is MIT, the default branch is master, the last push was on 2026-10-11, and the one listed release is v3.0, described as stts 3.0 with Tahoe support, from 2025-09-18.

Adding a service means running a script against a status page

The contribution model is unusual for a macOS app and worth understanding, because it tells you how the list of monitored services is actually built.

The README says most services can be added automatically with the included extract script. The contribution flow is a clone, an install of dependencies, and a run of the script against the URL of a status page:

# If you haven't already, clone the repo
git clone https://github.com/inket/stts.git
cd stts

# Install dependencies and run the extract script
bundle install
bundle exec ruby extract.rb <url>

# Example:
bundle exec ruby extract.rb https://status.notion.so/

So the script takes a status page URL and derives the service definition from it. The Notion status page is given as the worked example, which suggests the script handles a page that lists many individual components, because a status page for a hosted product typically publishes a row per service and a row per incident, and the useful thing to extract is the list of component names.

The repository layout backs this up. There is extract.rb and sort.rb, so there is a Ruby toolchain for the data side, and a Gemfile with a Gemfile.lock alongside a .bundle directory. The Gemfile is why the README uses bundle install and bundle exec rather than a plain ruby invocation.

There is also openai.html in the repository root, which reads as a saved copy of a service status page. It is likely there as a reference or a test fixture for the extraction logic, and it is the sort of artefact that shows the script works against a real captured page rather than against a mock.

For services that cannot be added with the script, the README asks you to create an issue. So the fallback is manual, with a human in the loop, and the script handles the common case.

The app is a normal Xcode project with a Carthage dependency and SwiftLint

The repository is a conventional macOS application layout, and the top-level entries describe it accurately.

There is stts.xcodeproj and stts.xcworkspace, which is the usual pairing when a project uses Swift Package Manager alongside CocoaPods or Carthage. The Cartfile and Cartfile.resolved files are the Carthage manifests, so the app pulls at least one dependency through Carthage rather than through Swift Package Manager. A Carthage-based dependency means the framework is fetched and built by Carthage rather than being vendored by hand.

The stts directory is the application target and sttsTests is the test target, so the project has automated tests from the start. The Resources directory holds the app's assets and the Scripts directory holds the build scripts, and.swiftlint.yml is present, which means the code is linted with SwiftLint and the configuration is committed, so the rules are visible to anyone who opens the project.

The.bundle directory at the root is the checked-in Bundler configuration, which is how the README's bundle install invocation resolves to the right gem versions on a contributor's machine. Combined with the Gemfile.lock, that makes the extract script's environment reproducible.

None of this is unusual, and that is the point worth making about the project: it is a small native app rather than a packaged or cross-platform one, built with the standard Apple toolchain, with the Ruby toolchain used only for the offline contribution task of harvesting service definitions. The two toolchains are kept separate on purpose, with the Ruby side producing data and the Swift side consuming it.

Where stts is the wrong tool

Three limits, and the first is the one that decides whether it fits your situation.

The first is what it actually monitors. It reads service status pages, which are published by the providers themselves and describe the provider's view of its own infrastructure. That is not the same as what your users experience, and the gap matters in exactly the situations you would want a status checker: a partial outage affecting only one region, a latency problem that has not triggered an incident, or an API degradation the provider has not yet posted about. A status page is a lagging indicator by construction, because it is written by the party that has to decide whether to admit a problem.

The second is that the distribution is the Mac App Store, and the repository is the source. The README says stts can be downloaded from the Mac App Store. That is the right choice for a consumer-facing utility, since it handles updates and signing, and it also means the app is sandboxed and subject to the store's review. A team that wanted to run this against internal services on a shared machine would find neither path convenient, since the store version is for the general case and the source build gives you the same public status pages.

The third is the release cadence. There is exactly one listed release, v3.0 with Tahoe support, from 2025-09-18, and the last push to the repository was on 2026-10-11, so development is continuing without a newer tagged release. For an app distributed through the Mac App Store this is less consequential, because the store handles versioning for users, but it does mean there is no changelog and no way to tell from the repository which changes shipped.

The alternative approach is to point a general purpose uptime tool at your own health endpoints. The difference in approach is that a status page tells you what a provider admits to, while a synthetic check against your own API tells you what your users are experiencing, and a proper alerting backend gives you history, escalation and grouping instead of a single transient popover. stts wins on setup, since there is nothing to configure and nothing to run on your infrastructure, and it loses on everything else. It is the right tool for a developer who wants to glance at a list of providers over coffee, and the wrong one for an on-call rotation.

What the project asks of its users

Two smaller points about how the project runs, which are worth knowing if you are thinking of depending on it.

The first is the funding and support arrangement. The README has a section asking for support with a Buy Me A Coffee link, alongside a Contribute section and a contact line pointing to the author's GitHub, Twitter and personal site. For a small utility that ships free through the App Store, that is a normal arrangement and nothing more than it.

The second is that the list of monitored services is community-maintained in a way that has a bottleneck. Most services are added automatically by the extract script, but the script can only work against status pages whose structure it understands, and for the ones it cannot handle the process is to open an issue and wait. That means the coverage of the app depends on one person's script parsing whatever the status page providers happen to publish this week, and on contributors who are willing to run it and open the pull request.

The consequence for a user is that the set of services in the list is uneven across providers, and uneven in a way that is not visible from the outside. Some large providers will be there and others will not, and the reason is usually a difference in how their status page is structured rather than a difference in importance. That is a fine design for a hobby project and a mild annoyance for someone who wants a specific service monitored and finds it missing.

If you do find a service missing, the path the README gives is an issue, and the script is the way to make that issue short for whoever picks it up. The script and the issue tracker are the two halves of the contribution loop.

Editorial conclusion

Adopt stts if you depend on a handful of hosted services and want to know about an outage without opening a browser tab, since the app polls status pages and notifies you on both an outage and a recovery. Do not adopt it as a monitoring system, because it reads public status pages rather than your own endpoints, so it tells you what a provider admits to rather than what your users are experiencing. Verify first that the services you care about publish a status page in a format the extract script can read, that the app's notifications go through your macOS notification settings in a way your team will actually notice, and that the single release listed, v3.0 for Tahoe support from 2025-09-18, matches the macOS version you run, since the last push was on 2026-10-11 without a newer tagged release.

Frequently asked questions

Official sources

1. inket/stts on GitHub
2. Issues
3. License: MIT
4. README
5. Releases