Soexya Khatiwada was midway through answering questions from a potential buyer when he changed his mind about selling GreenPing, the status page tool he’d built for small software teams.
Another project of his had just been wiped out overnight. It lived entirely on someone else’s platform, and there was no warning or opportunity to appeal.
That same week I looked at GreenPing differently: my own domain, my own code, and customers reach me by email. Nobody can delete it.
He pulled the listing and decided to put the time he’d been spending on the sale into marketing GreenPing instead.
It looks like a strange reversal from outside, but from inside it was the easiest decision I made all year.
Soexya is a builder from the UAE who works a full-time office job. GreenPing is the project he’s committed to.
The service uses UptimeRobot webhooks to turn monitoring alerts into public status updates, automatically opening and resolving incidents and notifying subscribers.
We spoke with him about why he kept the project, what building against real UptimeRobot alerts taught him, and how he designed GreenPing to run without him watching it.
The gap between detecting downtime and communicating it
There wasn’t one dramatic outage that inspired GreenPing. Soexya noticed the persistent problem of small software products going down without telling their users what was happening.
“There was no single disaster story, and I won’t invent one. What struck me was quieter: small tools kept going down and communicating it nowhere, or in a tweet nobody finds.”
Tools like UptimeRobot already handled outage detection. But getting from an alert to a customer-facing update often meant using systems designed for much larger teams.
“The gap was that everything between ‘my monitor pinged me’ and ‘my customers know’ was built for companies with an SRE team. I wanted the two-minute version: page up, monitor wired in, done.”
He built GreenPing around that idea. It’s a hosted status page for small software teams, with incident updates, subscriber emails, and support for custom domains. One page is free, while custom domains and removing GreenPing branding cost $9 per month.
Soexya draws a clear line between monitoring and communication.
The monitor answers ‘is it down?’. The status page answers ‘what are you doing about it?’
He also argues that a monitor shouldn’t double as a communication layer. If a status page shares infrastructure with the service that’s down, it can become unavailable at the same time.
GreenPing doesn’t probe customers’ servers, and Soexya says he’s made that explicit on the website after people assumed it did.
Detection should be automated, narration should be human. That’s the line that matters.
Building around real UptimeRobot alerts
Soexya built GreenPing’s UptimeRobot integration around the alerts the monitoring service actually sends, rather than starting with a generic webhook.
A generic webhook is a spec. A real integration is a promise.
That meant accounting for different payload formats. Depending on the webhook configuration, UptimeRobot alerts could arrive as JSON, form data, or query parameters with an empty request body.
GreenPing’s parser merges all three, giving priority to explicit keys in the body. One bug showed him why testing against real alerts mattered.
In query-parameter mode, my empty-body fallback treated recovery notifications as new outages, the exact opposite of the truth.
GreenPing uses UptimeRobot’s alert types to distinguish between an outage and a recovery. Getting that wrong meant a service coming back online could trigger another outage instead of resolving the incident.
Real payloads teach you what a spec never will.
The generic webhook, he says, “came later and was better for it.”
When GreenPing caught its own infrastructure problem
Soexya uses GreenPing to report on GreenPing’s own status. At status.greenping.live, UptimeRobot monitors send webhooks to a regular GreenPing account running the same code as every customer’s.
That setup eventually exposed a problem with GreenPing’s hosting.
Our API was on a hosting tier that put idle servers to sleep, and cold starts were sometimes slow enough that UptimeRobot correctly called it down.
When a cold start took long enough for UptimeRobot to register the API as down, the webhook changed the component’s status. A recovery alert followed a couple of minutes later, automatically resolving the incident.
Watching my own page flap showed me the problem was worse than I thought, so I fixed it. My status page found a real infrastructure issue for me.
Running his own product this way also means experiencing the same problems his customers might encounter.
Every rough edge a customer would hit, I hit first, in public.
Building a product that runs without him
Outside his full-time office job, Soexya builds small internet products that, in his words, “can run without me watching them.”
GreenPing follows that principle. When an alert arrives, it automatically changes the affected component’s status, opens an incident, and emails subscribers. A recovery alert resolves the incident. Custom domains are also provisioned automatically when customers add them.
The incident workflow is designed to run without Soexya having to intervene. The one exception is incident narration, which he deliberately leaves to the customer.
The only thing I don’t automate is incident narration, because that’s the customer’s voice, not mine.
His rule for deciding when a feature is finished is simple:
If it needs me awake to work, it isn’t finished.
What would make webhook integrations easier
Building the UptimeRobot integration also gave Soexya a few ideas for improving the developer experience.
First, he’d like a button that sends representative test webhook payloads. During development, he had to cause actual downtime on a test monitor to see the alert formats UptimeRobot would send.
He’d also welcome a single, consistent JSON schema, with query-parameter mode clearly marked as legacy, which he says would have saved him his worst integration bug.
His third suggestion is a signature header that would let receiving services verify that an alert genuinely came from UptimeRobot, instead of relying on a secret URL.
These suggestions come from the problems he encountered while developing the integration. He still appreciates how straightforward it was to get working.
The payload is refreshingly simple, which is why a small tool like mine was integrated in a weekend.
What’s next for GreenPing?
Soexya has decided to keep building GreenPing and put more time into getting it in front of small software teams. He still wants it to be a straightforward, affordable way to keep customers informed when something goes wrong.
A status page is a small, single-purpose tool and should be priced like one.
And after nearly selling it, he’s clear about why this particular project matters to him.
I was selling the one project where I owned the ground it stood on.
You can explore GreenPing at greenping.live or contact Soexya at hello@greenping.live.
