Uptime monitoring

Know the moment
your service goes down.

HTTP, ping, and keyword checks from German infrastructure. Intervals as fast as 30 seconds, every failure classified, every alert dispatched within seconds — no US cloud, no CLOUD Act, no DNS caching.

Free tier included · No credit card · Cancel anytime

Three steps

How it works.

Point a monitor at your service. Configure how often and how strict. Get alerted when things break.

01

Create a monitor

Pick a check type — HTTP, Ping, or Keyword — and enter the URL or host you want to watch. That is the minimum configuration required. Everything else has sensible defaults.

02

Pick a check type

Three ways to verify a service is alive — pick the one that matches what you are monitoring:

GET https://api.example.com/health HTTP
// every 30s from Nuremberg
GET https://api.example.com/health
 200 OK · 34ms · TLS 1.3

// verifies status code, response time, headers,
// SSL validity, DNS resolution, chain of trust.
03

Get alerted when it fails

Once the configured number of consecutive failures is hit, an incident is opened and alerts go out via email, Slack, Discord, or webhook. The incident auto-resolves the moment the next successful check arrives — and a resolution notification is sent.

Failure classification

What we actually detect.

Every incident is classified with its root cause so you can triage without guessing. No generic "site down" — the alert tells you what broke.

HTTP errors

4xx and 5xx response codes. Configurable — you decide whether a 401 is an incident or expected (e.g. for auth-gated health endpoints).

SSL certificate problems

Expiry, chain-of-trust issues, hostname mismatches. Classified as its own cause so you react before an outage hits your customers.

DNS failures

No record found, NXDOMAIN, timeout at the resolver. No DNS caching on our side — every check performs a fresh lookup.

Timeouts

Server unreachable, connection hang, or response slower than your configured timeout (default 10s). Captures degraded performance, not just hard outages.

Connection refused

Port closed, service not listening, firewall drop. Distinct from a timeout — means the host is up but the service is dead.

Keyword missing

Response returned 200 but the expected text is absent. Catches soft failures where a page renders an error or a WAF blocks content.

Direction matters

Uptime vs heartbeat.

Two approaches, one goal: knowing when something breaks. Uptime catches public outages. Heartbeat catches silent internal failures.

Uptime monitoringHeartbeat monitoring
DirectionFoundersDeck pings your serviceYour task pings FoundersDeck
Answers"Is my service responding?""Did my job run on time?"
Best forWebsites, APIs, endpointsCron jobs, scripts, workers
Failure modeDetects public outagesDetects silent failures
Why one is not enough

Your API can return 200 OK while the nightly backup has silently failed for a week. Your cron job can run perfectly while your website is down. Real reliability means monitoring both directions. FoundersDeck gives you uptime monitoring and heartbeat monitoring in one tool — all hosted in Nuremberg, Germany. No CLOUD Act, no data leaving the EU, no second vendor.

Choosing an uptime tool

FoundersDeck vs UptimeRobot, Better Stack, Pingdom.

The three most popular uptime tools are all US-based legal entities — meaning every byte of your monitoring data is subject to the CLOUD Act, regardless of which "region" you pick in their dashboard. Here is an honest side-by-side.

FoundersDeckUptimeRobotBetter StackPingdom
HeadquartersGermanyUSAUSA (Delaware)USA (SolarWinds)
CLOUD Act exposureNoneYesYesYes
Data residencyNuremberg onlyGlobal (US-operated)Global (US-operated)Global (US-operated)
Fastest interval30s (Scale)60s (free)30s60s
Monitoring locationsEU only (by design)GlobalGlobalGlobal
Heartbeat / cron
Public status pages
Paid entry tier€9 / month$7 / month$29 / month$15 / month
Pick a US-based tool if

You genuinely need global monitoring locations (e.g. you serve a worldwide audience and want to catch regional outages), you already operate in US compliance frameworks, or you need features that are truly category-defining like Pingdom's real-user monitoring.

Pick FoundersDeck if

Your audience is European, your buyers care about GDPR and CLOUD-Act exposure, you want uptime + heartbeat + status pages in one subscription, or you prefer a tool built by a founder who uses it to monitor his own business — not a venture-backed platform.

Configuration

Fine-tune speed vs noise.

Every knob you need to match the monitor to the service — without drowning yourself in configuration options you don't.

Check intervals
30s → 10m

30-second checks on Scale, 1-minute on Starter and Pro, 5-minute on Free.

Request timeout
1s → 30s

Hard cutoff after which the check is marked as timed out. Default 10 seconds.

Alert sensitivity
1 → 5 failures

Number of consecutive failed checks before an incident is opened.

HTTP methods
GET · HEAD

HEAD by default to minimize load on the monitored service — switch to GET when body inspection or keyword checks are needed.

Expected status
Any 2xx

Default is 200 — override per monitor for endpoints that return 201, 204, or custom codes.

Data retention
30d → 365d

30 days on Free, 90 on Starter, 180 on Pro, 365 on Scale — all stored in Germany.

Alert channels
  • Email
  • Slack
  • Discord
  • Webhook
FAQ

Frequently asked.

What is uptime monitoring?
Uptime monitoring is the practice of continuously checking whether a website, API, or service is reachable and responding correctly from the outside. FoundersDeck sends requests from German infrastructure on a fixed interval, records response time, status code, and error class, and alerts you the moment a service stops behaving as expected.
How often are my monitors checked?
Check intervals range from 30 seconds (Scale plan) to 10 minutes. The free plan runs on 5-minute intervals, Starter and Pro plans at 1 minute, and Scale at 30 seconds. Every check runs from EU infrastructure — no DNS caching, no shared agents with unrelated customers.
What is the difference between HTTP, Ping, and Keyword checks?
HTTP checks verify the full request/response cycle on ports 80/443 — status code, headers, SSL, DNS. Ping checks test basic network reachability via ICMP/TCP and are useful for services without HTTP endpoints. Keyword checks are HTTP checks that additionally verify a specific string is present in the response body — useful for detecting soft failures where a page returns 200 OK but renders an error.
Do you detect SSL certificate issues?
Yes. Every HTTPS check verifies the certificate chain, expiry, and hostname match. SSL errors are classified as their own incident cause (ssl_error) and appear separately in your incident history so you can react to certificate problems before they become outages.
How are false positives prevented?
Every potential outage is confirmed by multiple consecutive failed checks before an incident is opened — the exact number is configurable per monitor (1 to 5). Short network hiccups, transient upstream errors, and brief cold-start spikes do not page you. Only real, sustained problems trigger an alert.
What happens the moment a check fails?
A failing check is recorded with its status code, response time, and classified error type (timeout, DNS, SSL, connection refused, HTTP error, keyword missing). Once the configured number of consecutive failures is reached, an incident is opened and alerts are dispatched to every linked channel within seconds. The incident auto-resolves as soon as the next successful check arrives.
What alert channels are supported?
Email on every plan; Slack and Discord from Starter (€9/mo); Webhooks from Pro (€19/mo). Every channel also receives a resolution notification when the service recovers, so your team knows when to stand down.
Where is my uptime data stored?
All uptime check results, response-time history, and incident records are stored exclusively in Nuremberg, Germany on Netcup infrastructure. Retention runs from 30 days (Free) to 365 days (Scale). No data leaves the EU, no US legal exposure, no CLOUD Act, no FISA 702. See our trust & sovereignty page for details.