Uptime monitoring for EU teams
If your product runs in Europe, the tool watching it should too. This guide covers what EU-based uptime monitoring gives you — EU probe origin, EU-stored incident data, the monitor types that matter, heartbeats for the jobs you run yourself, and public status pages — and how MOJAQ puts them in one Helsinki-hosted account.
EU-hosted in Helsinki · GDPR-native · free during the private beta
Why EU uptime monitoring
Monitoring metadata is easy to overlook because it is not customer data in the usual sense. But your monitor names, endpoint URLs, ports and incident history are a fairly precise map of your infrastructure, and shipping that continuously to a non-EU service is the same category of decision as choosing where your database lives. MOJAQ probes from the EU and keeps the resulting incident data in Helsinki with a DPA, so the map of your systems stays in the EU.
The monitor types that matter
| Type | What it watches |
|---|---|
| HTTP | Endpoints and pages — status codes, response time and keyword checks. |
| TCP / port | Services that are not HTTP: databases, brokers, mail, custom ports. |
| ICMP (ping) | Basic host reachability and round-trip latency. |
| DNS | Resolution correctness — catch a record that changed or disappeared. |
| gRPC | Health of gRPC services without wrapping them in an HTTP shim. |
| Push heartbeat | Jobs you run yourself: the job pings a URL, and a missing ping alerts you. |
Heartbeats: the failure external checks miss
An outbound HTTP check confirms that a URL answered. It cannot confirm that your nightly backup ran, that the queue worker is draining, or that the data export finished. Those jobs fail silently — nothing errors, the thing just never happens — until someone notices days later. A heartbeat closes that gap: your job pings a URL when it completes, and if the ping does not arrive within the window you set, the check goes down and you get alerted.
# at the end of your job, ping your MOJAQ heartbeat URL # (copy the exact URL for each heartbeat from your dashboard) curl -fsS -m 10 "$MOJAQ_HEARTBEAT_URL" || echo "heartbeat failed"
You configure the expected interval and a grace period so a job that is a little late does not page anyone, but a job that genuinely stopped does.
Status pages, without exposing internals
When something is down, customers want a clear public signal, not your raw check output. MOJAQ includes public status pages with your own custom domain and branding, so you can communicate service health cleanly while the detailed diagnostics stay inside your account. Because uptime lives beside your errors, logs and deploys, the incident you are communicating is already correlated with the release and errors behind it.
Get started
Create a free account and add your first monitors — the URLs, ports and services you care about — then add heartbeats for the jobs that fail quietly. Set alert channels (Slack, Discord, webhook or email), publish a status page on your own domain, and you have EU-hosted uptime, heartbeats and status all in one place.
Questions
Why does EU uptime monitoring matter?
Your monitor list, endpoints and incident history describe your infrastructure, and that metadata deserves the same residency thinking as your application data. MOJAQ probes from the EU and stores the incident data in Helsinki with a DPA.
What can MOJAQ monitor?
HTTP, TCP, ICMP, DNS and gRPC checks on a 30-second interval, plus push-heartbeat monitors for jobs you run yourself. You get response-time graphs, up, down and degraded states, and incident timelines.
Can I publish a status page?
Yes. MOJAQ includes public status pages with your own custom domain and branding, so customers see service health without exposing raw diagnostics.
How do alerts reach my team?
Through Slack, Discord, webhook or email. You choose the channels per monitor, so the right people hear about the right outage.
Watch your uptime from the EU
HTTP, TCP, DNS and heartbeat monitors with EU-stored incidents and public status pages. Free while we are in beta.
Request beta access →