Most of my public work is WordPress: plugins, integrations, the occasional theme. This one is not. UptimeClaw is an uptime monitoring service I built and run, and it has no WordPress in it at all.
I am putting it here because “WordPress developer” describes what is visible, not what the work is. Building an uptime monitoring service is a different discipline. It means scheduling, distributed failure, notification delivery, and a lot of thinking about what counts as “down”.
What it does
UptimeClaw watches websites, APIs and servers, then tells you when they stop answering. Three kinds of check cover most of what people need:
- HTTP(S): status codes, response times and headers. Custom auth and header injection are there for endpoints that need them
- Keyword: verify that specific text is present, or absent. This catches a defacement or a silently broken template, where the page still returns 200
- Network: ping and port checks over TCP, UDP and ICMP
Alerts go out by email, webhook or WhatsApp. The webhook format works with Slack, Discord and PagerDuty. Five monitors are free, with no credit card. Checks run every five minutes on the free tier and every minute on paid plans. Every monitor also gets a public status page with ninety days of history.
The parts that are not a website
A monitoring product looks simple from outside. You request a URL on a timer and shout if it fails. Nearly all the engineering is in the word “fails”.
The hard part is not alerting. A single failed request means very little. Packet loss happens. A CDN edge hiccups. A TLS handshake times out under load. Page someone for each of those and they will mute you inside a week. At that point the service is worse than nothing. Therefore a failure gets re-probed before it becomes an incident.
Delivery is its own problem. An alert that arrives beats an alert that is merely correct. So notification is a queue with retries, not a function call. Email, webhook and WhatsApp all fail in different ways, and they fail most often exactly when something large is broken.
Then there is state. Uptime percentage over ninety days means storing every result. It also means surviving restarts, and being honest about gaps in your own collection. A monitoring service that quietly stops checking and reports 100% is lying.
Why an uptime monitoring service is on a developer site
Because it answers a question the plugin pages cannot. Plugins prove I can work inside somebody else’s framework and ship to tens of thousands of installations. They do not prove I can design a service. Nor that I can run the infrastructure under it, or reason about a system that must keep working while nobody watches.
The same skills show up in ordinary client work. A deploy breaks in production. A queue silently stops draining. A site is fine in staging and wrong under real traffic. Consequently, all of those are the same category of problem as deciding whether a host is down.
Have something in that category? Get in touch and describe the symptom. Meanwhile, the contributions page lists the open-source side: plugins, PHP packages and editor extensions.