Building StatusWatch: A Multi-Service Status Checker with Ballerina

Chiran keshawa Weerasekara — Sat, 14 Nov 2026 23:28:12 +0000

Building StatusWatch: A Multi-Service Status Checker with Ballerina

By Chiran Keshawa Weerasekara

Introduction

Have you ever tried to push code to GitHub or install an npm package, only to find that something isn't working? When that happens, one of the first things I usually wonder is whether the problem is in my code or whether the service itself is experiencing an issue.

To find out, I would normally open separate browser tabs for GitHub, Cloudflare, and npm and check their status pages one by one. It works, but doing the same thing repeatedly can become a little frustrating.

I decided to build a small project to make this easier. I called it StatusWatch. It is a backend service built with Ballerina that checks the current status of GitHub, Cloudflare, and the npm Registry and combines the results into a single response.

The main idea was simple: instead of checking three services separately, I wanted to get all their status information in one place.

Why I Chose Ballerina

For this project, I wanted to try something different from the languages and frameworks I normally use. I chose Ballerina, an open-source programming language developed by WSO2.

Ballerina is designed to make working with APIs and network services easier. Since this project mainly involves communicating with external APIs, it felt like a good opportunity to explore the language and understand how it handles these kinds of tasks.

One feature that interested me was Ballerina workers. They allow independent tasks to run concurrently, which was useful because I didn't want the application to wait for one status check to finish before starting the next one.

How StatusWatch Works

The application has a single endpoint:

GET /health/overview

When this endpoint is called, StatusWatch starts three checks:

GitHub Status API
Cloudflare Status API
npm Registry Status API

Rather than calling them one after another, I used Ballerina workers to start the requests concurrently. The application then waits for the results and combines them into one response.

For example, if GitHub takes 300 milliseconds, Cloudflare takes 1,100 milliseconds, and npm takes 500 milliseconds, checking them sequentially would take roughly 2 seconds based on those response times. Running them concurrently means the application can finish much closer to the time taken by the slowest request.

This approach follows a pattern often called Scatter-Gather. In simple terms, the application sends requests to multiple services and gathers their responses into one result.

Here is a small part of the implementation:

worker wGithub returns ServiceHealth {
    return fetchStatus(githubClient, "GitHub");
}

worker wCloudflare returns ServiceHealth {
    return fetchStatus(cloudflareClient, "Cloudflare");
}

worker wNpm returns ServiceHealth {
    return fetchStatus(npmClient, "npm Registry");
}

ServiceHealth gh = wait wGithub;
ServiceHealth cf = wait wCloudflare;
ServiceHealth npm = wait wNpm;

Once all three checks are complete, their results are combined into a single system overview.

Handling Different Service Responses

Another part of the project was handling the different responses returned by the services.

Status APIs can report different conditions, such as operational, minor issues, major issues, or critical incidents. I added a small mapping function to convert these responses into a consistent format:

OPERATIONAL – The service is working normally.
DEGRADED – The service is experiencing some problems.
OUTAGE – The service has reported a major issue.
UNREACHABLE – The application could not retrieve the service status.

I also wanted to make sure that one failed request would not affect the entire application. For example, if Cloudflare does not respond, StatusWatch can still return the results from GitHub and npm.

After collecting the results, the application calculates an overall status, such as ALL_OPERATIONAL, PARTIAL_OUTAGE, or MAJOR_OUTAGE.

This makes the response easier to understand without having to inspect each service separately.

Testing It with Real Services

After completing the main functionality, I started the Ballerina service locally and tested the endpoint using curl:

curl http://localhost:9090/health/overview

During one of my live tests on November 13, 2026, I received a partial outage response. GitHub and Cloudflare were reported as degraded, while the npm Registry was operational.

I checked the official status pages to compare the results and found incident notices matching the issues reported by my application.

Seeing the application identify different service conditions during a real test was one of the most satisfying parts of building this project. It also gave me a chance to see how the application behaved when not every external service was operating normally.

Testing and GitHub Actions

I also added unit tests in tests/service_test.bal to check the application's endpoints and status-mapping logic.

The tests can be executed using:

bal test

To make the project easier to maintain, I set up a GitHub Actions workflow in .github/workflows/build.yml. It runs the test suite using a Ballerina container whenever I push changes to the repository.

This helped me make testing part of the development process instead of relying only on manual testing.

What I Learned

Building StatusWatch gave me an opportunity to explore Ballerina through a practical project rather than just reading about its features.

A few things I learned along the way:

Working with APIs: I gained more experience connecting to external APIs and processing their responses using Ballerina.
Concurrent execution: I understood how workers can help reduce waiting time when an application needs information from multiple services.
Error handling: I learned why external services should be treated as unreliable and why one failed request should not bring down an entire application.
Testing and automation: Setting up unit tests and GitHub Actions helped me understand the importance of checking code changes automatically.

I also found that Ballerina made it straightforward to work with HTTP requests and JSON responses without needing to depend on many additional libraries.

Final Thoughts

StatusWatch started as a small idea to avoid opening multiple status pages whenever something went wrong during development. It turned into a useful opportunity to explore Ballerina and understand how it can be used to build API-based services.

The project is fairly small, but it helped me learn more about concurrent API requests, error handling, and automated testing. More importantly, it gave me a chance to build something practical while exploring a technology I had not used much before.

You can find the source code, tests, and setup instructions here:

GitHub Repository: https://github.com/chiranke-beep/statuswatch-service

Thanks for reading!

DEV Community: Chiran keshawa Weerasekara

Building StatusWatch: A Multi-Service Status Checker with Ballerina