Everything your product depends on, watched from outside.
Most monitors stop at “is the page up”. OpenPing also checks the parts that fail quietly: an MCP server that lost a tool, a gateway that fell back to another model, an agent whose answers got worse.
What it watches
| What you watch | What OpenPing checks |
|---|---|
| Websites | Up or down, status code, load time, words that must or must not be on the page, redirects and page size, from more than one region. |
| APIs | A call with checks on the status, the headers, JSON fields and the schema. Sign-in with a bearer token, a header, basic auth or OAuth client credentials. |
| MCP servers | The handshake (new and older protocol versions), the sign-in flow, the tool, resource and prompt lists, changes to tools including hidden instructions in their descriptions, a safe test call, and speed per step. |
| AI gateways and LLM APIs | The models list and a tiny streamed reply for each model you pick: time to first token, tokens per second, and which model answered. |
| Agents and their answers | Test questions sent on a schedule and after every deploy. Answers are checked by rules and by an AI judge, and the pass rate is tracked over time. |
| IPs and networks | Ping (packet loss and latency), TCP ports, and DNS records and changes to them. |
| Scheduled jobs | Heartbeats: the job calls a URL when it starts and when it ends. You hear when it is late, fails or runs too long. |
| Certificates and domains | Certificate expiry, chain and hostname; domain expiry. |
| Incidents and status pages | Incidents that open themselves, with a timeline and a summary in plain words. Public status pages that can say when answers get worse. |
How a failure is confirmed
One failed check is not an outage. Each run goes out from one region. When it fails, two other regions try again at once. A monitor is Down only when two of the three fail, and it is Up again only after two passes in a row. If the other two pass, the blip is kept in the history and nobody is woken.
- A region we cannot hear from never pages anyone. A missing answer counts as a pass.
- Our problem, not yours. If many unrelated monitors fail from one region at once, that region is set aside and its failures stop counting.
- Flapping folds into one alert. A monitor that flips more than 4 times in an hour sends one message, not a storm.
- Degraded is its own state. The check passed but too slowly, or an agent’s pass rate fell below its target. It says so in words: “Degraded”, never just a colour.
The rules we build by
- One URL in, monitoring out in 60 seconds. No agent to install, no YAML, no card to start. You see results before we ask for an account.
- Up and right. Every AI check asks two questions: did it answer, and was the answer right?
- Calm alerts. Confirm from a second place before alerting. One cause makes one incident. A false alarm is a bug.
- Explain everything. Every suggested monitor says why. Every alert says what failed, where, since when, and what changed just before.
- Open by default. The probe and the CLI are open source. Monitors can live as code in your repo. Status pages speak the Statuspage API.
- Honest status pages. They show what your users feel, including answer quality, in plain words.
- Agents are users too. Everything in the app is also in the API, the CLI and the MCP server.
- Fair prices. Pay for monitors and runs, not seats. The free plan can run a real product.
- Take as little as possible. We store only what a check needs and remove personal data from samples.
- Never be the outage. The watcher is built to stay up when everything else is down.
Planned, not in the first release
We would rather say so here than let you find out later.
- Browser journeys with screenshots
- API chains, gRPC and WebSocket
- On-call rotas, SMS and calls
- Private probes inside your network
- Imports from other tools
- A GitHub app and app-builder connectors
See it on your own product
Paste a URL on the home page and watch what OpenPing finds. No account needed for the first look.