Uptime monitoring
HTTP checks from EU locations, evaluated against your own rules — status code, body content, certificate — with confirmation logic that filters transient failures before anyone is alerted.
Hosted in the EU
GDPR-friendly by design
Core monitoring data stays in the EU
01
WatchCat requests your endpoint as often as every minute, from several EU regions
02
Each response is checked against your rules: status code, body content, SSL certificate, timeout
03
A failure has to hold across regions and through a confirmation period before an incident opens
04
Recovery is detected automatically and closes the incident
Scheduled checks
- Checks run at the interval you choose, such as every 1 minute or 3 minutes.
- Each check stores the observed status and response time.
Request and rules
- GET, HEAD, POST, PUT, or PATCH, with custom headers and cookies. POST, PUT, and PATCH can send a static JSON body, for GraphQL and JSON-RPC endpoints.
- Expected status codes as patterns such as 2xx or 401, redirect handling, and a request timeout.
- Body must contain or must not contain a string, and the SSL certificate must be valid. An HTTP 200 can still fail a rule, and the check shows which one.
Failure detection
- Checks run from several EU regions. A monitor is only failing when every region sees the failure, so one region's network blip is not your outage.
- The first failed check is recorded, but the monitor is not marked down immediately. WatchCat waits for a confirmation period before changing the monitor to DOWN.
- Short blips clear before an incident opens, so they never alert anyone.
Recovery and incidents
- An incident is created when the monitor transitions to DOWN.
- Recovery requires stable successful checks, not just one lucky response.
- The incident is resolved when the service has recovered.
Regions
Monitoring locations
Uptime checks run from configured European locations.
-
Austria
-
Finland
-
Germany
Why it matters
Fewer false alerts, faster real ones
- Checks run from EU infrastructure — core monitoring data stays in the EU
- Confirmation logic waits for failure to stabilise — fewer false alerts
- Body and certificate rules — catch a 200 that returns an error page, or an expired certificate
- Response time tracked per check — spot degradation before it becomes an outage
Use cases
Typical use cases
- A checkout API — you need to know within minutes if it stops responding
- A customer-facing app on a VPS you manage alone, with no ops team behind it
- An internal tool the team relies on but no one outside will ever report as down
Start monitoring for free
5 monitors free · no credit card required