OpenStatus works well for synthetic monitoring: OpenStatus checks a service, changes monitor state, updates status pages, and sends notifications.
The gap is partial failures. A monitor may show that Service A is up, while a subset of deployments, regions, routes, or customers are seeing 503s or 504s. Those failures may be unrelated to the specific endpoint the synthetic monitor is checking.
Creating separate monitors for every deployment, region, route, and failure mode is not sustainable. But application code often knows when one of those slices is failing.
Today, those systems can trigger an OpenStatus monitor check, but they cannot directly report:
This service is degraded or failing, here is the context, please update the monitor/status workflow.
That means teams either hope a synthetic check reproduces the issue, create too many narrowly scoped monitors, create separate status reports, or build alerting outside OpenStatus.
Proposal
Add a Manual Monitor or External Monitor type.
This monitor would use the same OpenStatus status page, incident, history, and notification infrastructure as normal monitors, but its state would be updated by authenticated external reports instead of scheduled pings.
Teams should be able to:
- create a monitor for an externally observed service or signal
- report
healthy, degraded, or failing from their own systems
- attach basic structured context, such as status code, route, region, request ID, and message
- have application-observed errors contribute to the same overall monitor data
- have OpenStatus update linked status page components
- have OpenStatus send existing notifications
- report recovery through the same path
Why It Matters
Synthetic monitors answer:
Can OpenStatus reach this service from the outside?
Manual monitors would answer:
Did the production system itself observe a real failure?
Both should feed the same monitor history, status page, incident, and notification experience. The goal is to keep all service health data in one place, even when some of that data comes from application code rather than an OpenStatus ping.
Success Criteria
A user can report an externally observed failure into OpenStatus and OpenStatus will:
- record the event
- update the monitor state
- update the status page
- send configured notifications
- show enough context for an operator to understand what happened
- accept a later recovery event
OpenStatus works well for synthetic monitoring: OpenStatus checks a service, changes monitor state, updates status pages, and sends notifications.
The gap is partial failures. A monitor may show that Service A is up, while a subset of deployments, regions, routes, or customers are seeing 503s or 504s. Those failures may be unrelated to the specific endpoint the synthetic monitor is checking.
Creating separate monitors for every deployment, region, route, and failure mode is not sustainable. But application code often knows when one of those slices is failing.
Today, those systems can trigger an OpenStatus monitor check, but they cannot directly report:
That means teams either hope a synthetic check reproduces the issue, create too many narrowly scoped monitors, create separate status reports, or build alerting outside OpenStatus.
Proposal
Add a Manual Monitor or External Monitor type.
This monitor would use the same OpenStatus status page, incident, history, and notification infrastructure as normal monitors, but its state would be updated by authenticated external reports instead of scheduled pings.
Teams should be able to:
healthy,degraded, orfailingfrom their own systemsWhy It Matters
Synthetic monitors answer:
Manual monitors would answer:
Both should feed the same monitor history, status page, incident, and notification experience. The goal is to keep all service health data in one place, even when some of that data comes from application code rather than an OpenStatus ping.
Success Criteria
A user can report an externally observed failure into OpenStatus and OpenStatus will: