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
5s → 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.

Request shape
6 methods

GET, HEAD, POST, PUT, PATCH, or DELETE — with custom headers, a request body, and Basic or Bearer auth. Redirects followed by default.

Expected status
Lists · ranges

Default is 200 — accept a list, a range like 200-204, or a whole class like 2xx, per monitor.

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
  • Telegram
  • Webhook
  • Microsoft Teams
Under the hood

More than a URL and an interval.

Shape the exact request, assert the exact response, and watch the things around your endpoint — certificates, domains, DNS records — that quietly cause outages.

Request configuration

Every HTTP monitor sends the exact request you need. Choose the method — GET, HEAD, POST, PUT, PATCH, or DELETE — add custom headers, a request body, and Basic or Bearer authentication. Set the request timeout (default 10 seconds, up to 30) and toggle whether redirects are followed. Request configuration is available on every plan.

Expected status codes

Tell each monitor which responses count as healthy. Enter a single code, a comma-separated list, a range like 200-204, or a class such as 2xx. Anything outside the set opens an incident classified as an HTTP error — so an auth-gated endpoint that returns 401 by design never pages you.

SSL certificate & domain expiry

Every HTTPS monitor watches its TLS certificate automatically — zero configuration. FoundersDeck warns you 30, 14, 7, and 1 day before a certificate expires. Domain-expiry monitoring (Starter and up) checks your registration via RDAP and warns 30, 14, and 7 days out, so a lapsed renewal never takes your site offline.

DNS monitoring

A dedicated DNS monitor type (Starter and up) resolves A, AAAA, CNAME, MX, TXT, or NS records and compares them against the values you expect — as an exact match or a contains check. Catch hijacked records, dropped MX entries, or a propagation mistake before your email or traffic silently breaks.

Degraded status

Slow is not the same as down. Set a response-time threshold per monitor and any check that responds successfully but slower than that is marked degraded — still counted as available, but visible on your response-time chart and status page. You see performance eroding long before it becomes a hard outage. Available on every plan.

Alert reminders & channels

Alerts reach Email on every plan; Slack, Discord, and Telegram from Starter; Webhook and Microsoft Teams from Pro. Route channels per monitor, so the right team hears about the right service. For a sustained outage, reminder alerts (Starter and up) re-notify at 15, 30, 60, or 240-minute intervals until it recovers — and a recovery notification closes the loop.

Reports & incident documentation

On Pro and up, export typeset PDF uptime reports (monthly, quarterly, or yearly) and per-incident PDF reports, plus CSV exports of the raw check log and incident history. These give time-stamped availability evidence to support your incident-reporting documentation under § 30 BSIG (NIS2). They support your duties; they do not by themselves make you compliant.

365-day uptime history

Daily uptime rollups give every plan — including Free — a full 365-day uptime figure, viewable over 24-hour, 7-, 30-, 90-, and 365-day windows. The daily rollups are retained for two years, so year-over-year reliability trends stay available even where raw per-check logs have aged out.

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, Discord, and Telegram from Starter; Webhooks and Microsoft Teams from Pro. Alert channels are assigned per monitor, and for a sustained outage reminder alerts re-notify at 15, 30, 60, or 240-minute intervals (Starter and up). Every channel also receives a resolution notification when the service recovers.
Does FoundersDeck monitor SSL certificate expiry?
Yes, automatically. Every HTTPS monitor watches its TLS certificate with zero configuration and warns you 30, 14, 7, and 1 day before it expires. Certificate-expiry monitoring is included on every plan, including Free, so a forgotten renewal never turns into a silent outage.
Can I send POST requests with custom headers?
Yes. Every HTTP monitor lets you choose the method (GET, HEAD, POST, PUT, PATCH, or DELETE) and add custom headers, a request body, and Basic or Bearer authentication. This works on every plan, so you can monitor authenticated API endpoints and webhooks the way they are actually called.
Can I monitor DNS records?
Yes. A dedicated DNS monitor type (Starter and up) resolves A, AAAA, CNAME, MX, TXT, or NS records and compares them against the values you expect, as an exact match or a contains check. It catches hijacked records, dropped MX entries, and propagation mistakes before traffic or email breaks.
Does FoundersDeck warn me before my domain expires?
Yes, on the Starter plan and up. Domain-expiry monitoring queries your registration over RDAP and warns you 30, 14, and 7 days before the domain lapses. It runs alongside your uptime checks so a missed renewal never quietly takes the whole site down.
What is degraded status?
A check that responds successfully but slower than a response-time threshold you set is marked degraded instead of down. It still counts as available, but appears on your response-time chart and status page, so you can see performance eroding before it becomes a hard outage. Available on every plan.
How long is uptime history retained?
Daily uptime rollups give every plan a full 365-day uptime figure, viewable over 24-hour, 7-, 30-, 90-, and 365-day windows. The daily rollups are kept for two years. Raw per-check logs are retained from 30 days on Free up to 365 days on Scale.
Can I export uptime and incident reports?
Yes, on the Pro plan and up. Export typeset PDF uptime reports (monthly, quarterly, or yearly) and per-incident PDF reports, plus CSV exports of the raw check log and incident history. They provide time-stamped availability evidence to support your incident-reporting documentation under § 30 BSIG — they support your duties; they do not by themselves make you compliant.
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.