Everything AppHealthMeter does

Getting started

AppHealthMeter checks whether your websites, APIs and cron jobs are running and tells you when they stop. Setting up the first monitor takes about two minutes and nothing needs to be installed on your side.

Sign-up is temporarily closed — we are finishing preparations before letting the first users in. Write to support@apphealthmeter.com and we will let you know when sign-ups open. Invitations to existing accounts work as usual.

1. Create an account (email + password). We send a verification link, valid for 24 hours. If the link did not arrive or has expired, try signing in — with an unverified address and the correct password the login screen offers to send a new link. The new link invalidates the previous one and is again valid for 24 hours; we send at most 3 links per 15 minutes to one address.
2. The link opens a page with a “Confirm e-mail address” button — after clicking, the account is active and you are signed in right away. Merely opening the link (e.g. by a mail scanner) does not consume the token. Your address becomes the first alert channel.
3. Right after confirmation you receive a contract confirmation email: the versions of the Terms of Service and Privacy Policy you accepted (with dates and links), a summary of the beta terms, the provider’s details and — if you are a consumer — information about your right to withdraw from the contract within 14 days. Keep that message: it is the confirmation of the contract on a durable medium.
4. Click “Add monitor”, pick a type (HTTP, SSL certificate, heartbeat or domain) and enter the address or interval.
5. From now on the monitor is checked periodically and outages land in your inbox.

Getting-started checklist

After your first sign-in the top of the dashboard shows a checklist that leads to your first working alert: add the first monitor, confirm a notification channel, send a test notification and — if you manage the team — optionally invite somebody to the account. Every step has a button that takes you straight to the right place in the panel.

Step state is computed from your data (monitors, notification channels, team members), so the list tells the truth after you switch browsers or devices too. The one exception is the fact that a test was sent — that is remembered by the browser, so on a new device the step may come back as not done (the worst that happens is one extra test notification). The list disappears on its own once the required steps are complete — inviting the team is optional and does not block it. You can also hide it earlier with the “Hide checklist” button.

Monitors and check types

A monitor is one thing we watch. It has a name, a check type, frequency settings and its own alert policy. You can edit it, pause it (pausing stops checks but keeps history) and delete it.

HTTP / HTTPS

• Enter the full address with http:// or https://. Redirects are followed.
• Interval (how often we check) — the minimum depends on your plan, see the table below. Timeout (1–60 s, default 30 s) — after that the check counts as failed; values outside the range are rejected by the form. The same range applies to SSL certificate and domain monitors.
• A check reads at most 1 MiB of the response — the status depends solely on the HTTP status code, the body is not analysed today. A check that, despite the timeout, exceeds the engine’s time limit (120 s — e.g. a chain of very slow redirects) is recorded as “Down” with a time-limit message.
• HTTP method — GET by default; HEAD, POST, PUT, PATCH, DELETE, OPTIONS and QUERY are also available. HEAD saves bandwidth, but some servers and CDNs reject it with 405. The Free plan allows HEAD only — the other methods start with the Individual plan (see “The Free plan” below).
• Up HTTP status codes — 200–399 by default. You can pick your own set: whole classes (2xx, 3xx…) and individual codes, e.g. 2xx + 401 — handy for APIs that answer 401 without a token but are up. We compare the final response status (after redirects). Any other status, a timeout or no connection means “Down”. We record the response time and HTTP status of every check.
• Checks identify themselves as AppHealthMeter/1.0 (+https://apphealthmeter.com/bot) in the User-Agent header. What the operator of the checked site sees and how they can block us is described on the bot page. Checks do not read robots.txt.

SSL certificate

• Enter host or host:port (default 443).
• We check the certificate’s expiry date: less than 14 days left means “Degraded” and a separate “SSL certificate expiring” incident; an expired certificate is “Down”.
• The monitor card always shows how many days remain until expiry (with the date); the check history also shows the issuer.

Heartbeat (cron, worker, backup)

The reverse of a classic monitor: your job reports to us, and we alert when the report does not arrive. Ideal for cron jobs, queues and backups that cannot be reached from the outside.

• After creation you get a unique address https://api.apphealthmeter.com/ping/<token>. A GET or POST at the end of the job is enough (e.g. curl -fsS ...). Ready-made snippets for curl, a crontab entry, a bash script, a systemd unit, a Kubernetes CronJob and a GitHub Actions workflow are in the monitor’s “Integration” tab — with the address and schedule filled in.
• Interval schedule: the expected gap between reports (minimum 30 s) plus a grace period (default 30 s). No report after both have passed opens a “Missed heartbeat” incident. A new heartbeat that has not received any report yet is counted from its creation — it gets a full interval plus grace before we consider it missed.
• Cron schedule: a 5-field cron expression (e.g. 0 3 * * *) in an IANA time zone (e.g. Europe/Warsaw; the form suggests your browser’s zone). A report is missed when it has not arrived by the most recent scheduled time plus the grace period. Daylight-saving changes are handled correctly, and scheduled times before the monitor was created are never treated as missed.
• /ping/<token>/fail (GET or POST) reports an explicit job failure — a “Reported failure” incident opens immediately, without waiting for the deadline. The request body (up to 4 KB, e.g. the tail of a log) is shown in the check history. A failure report counts as a report (the job did run), so we will not open a second “Missed heartbeat” incident for it.
• The full token is shown only once, at creation; afterwards we show its tail. You can generate a new one at any time (the old one stops working). A short payload (up to 4 KB) can be attached to a report and is stored with the check.

Domain

• Enter the domain without scheme or path (e.g. example.com).
• Once a day we ask the registry (RDAP) for the registration expiry date. Less than 30 days means “Degraded” and a “Domain expiring” incident; less than 7 days (or expired) means “Down”.
• The monitor card always shows how many days remain until expiry (with the date); the check history also shows the registrar. The interval cannot be changed — RDAP limits.
• A domain monitor counts towards the monitor pool (like HTTP and SSL), not heartbeats.

Plan limits

HTTP/SSL monitors and heartbeats have separate pools. The minimum interval depends on the plan — the monitor form will not accept a lower value, and the check engine runs on a 10 s tick. A monitor’s next check starts only after the previous one has finished — with an interval shorter than the timeout, a slow endpoint is checked less often than the interval says. The Free plan has extra rules (HEAD only, a sign-in requirement, a limited number of slots) — see “The Free plan”. How much of your limits is already in use is shown under “Account → Account” (see “Team and account”).

Statuses, incidents and alert rules

Every monitor has one of five statuses:

• Operational — the last check succeeded.
• Down — the last check failed (error, timeout, 4xx/5xx, missed report).
• Degraded — working, but needs attention (e.g. certificate expiring in under 14 days).
• No data — the monitor has not been checked yet or is paused.
• Maintenance — a maintenance window is active, checks are paused (see below).

Check history

The “Checks” tab in the monitor details shows the response time chart and the checks table, newest first. The “From” and “To” fields narrow both views to a date and time range (your browser’s time zone, both ends inclusive); you can set just one of them. 50 checks are shown at a time and “Show more” loads further ones — up to 500. The range reaches as far back as your plan’s check history retention.

Incidents

An incident is one continuous period of unavailability: it opens when a monitor stops working and closes on the first successful check. You will find it on the “Incidents” list (open / closed / all, with duration) and in the monitor’s incidents tab. The number of ongoing outages is shown next to the menu item.

The incident list is paginated, 25 entries per page: above the table you see the range and the total (e.g. “1–25 of 63”), below it the page number and the “Previous” / “Next” buttons. The filters (open / closed / all, and label) apply to the whole account history, not just the visible page — changing a filter takes you back to the first page of results. The incidents tab in a monitor’s details shows only that monitor’s incidents, and the counter next to the menu item counts all ongoing outages, not just those on the current page.

Alert rules (in the monitor form)

• Confirmation threshold (1–10, default 2): how many consecutive failed checks must occur before we open an incident. Protects against alarms caused by a single dropped packet. For heartbeats a missed report after the grace period is confirmation enough.
• Alert delay (0–3600 s): the incident opens immediately, but the notification goes out only if the outage lasts longer than this. Short blips do not wake anyone at night.
• Reminders (default every 8 h; 10 min – 24 h or off): while the outage lasts, we send another notification at this cadence.
• Alerts on / off: mute notifications without pausing checks. History and uptime keep counting.
• Recipients: selected channels; nothing selected means all active channels of the account.

Notifications

Today notifications go out by email. Push notifications (mobile app — coming soon) and webhooks are in preparation.

• Every team member’s address becomes a channel automatically once their account is verified. If a member is still “Pending”, you can resend the verification link from “Account → Notifications”.
• Under “Account → Notifications” you can add extra addresses (e.g. ops@company.com). Each receives a verification link; alerts flow only after confirmation. The link can be re-sent.
• Test notification. Every channel under “Account → Notifications” has a “Send test notification” button. The message travels the same path as a real alert, so it verifies the actual setup: whether the email arrives and does not land in spam, whether the phone shows the notification. It works for email channels and mobile devices, but only for verified and enabled ones — for the rest the button is greyed out with a hint why. Limit: 5 tests per hour per channel (once exceeded you get a message and simply try again later). Tests do not count towards the alert email limit described below and carry no unsubscribe footer — they are not alerts.
• We send three kinds of messages: outage (with reason and time), recovery (with duration) and a reminder about an ongoing outage. For certificates and heartbeats the content is tailored to the kind of problem.
• The alert footer has a “False alarm?” link. It opens a page with a confirmation button (merely opening the link changes nothing — mail scanners will not flag the incident for you); after clicking, the incident is flagged, and we use those reports to improve detection. The link is valid for 30 days from sending.
• One-click unsubscribe. Every alert has an “unsubscribe this address” link in the footer, and mail clients (Gmail, Apple Mail…) show their own “Unsubscribe” button next to it — that one works instantly. The footer link opens a page with a confirmation button (merely opening it changes nothing). After unsubscribing, the email channel is disabled and alerts stop going to that address; the monitors keep running. You can re-enable it under “Account → Notifications”. The link is valid for 90 days and applies to alerts only — account messages (verification, password reset, contract) have no unsubscribe.
• Alert email limit: 60 per hour per account (clock hour, UTC). Once exceeded, further alert emails in that hour are not sent, and the account owner receives a single “we paused email notifications” message with the number of alerts sent and the time they resume. Monitors keep running, incidents are recorded and visible in the panel, and push notifications (once available) are not subject to this limit. Emails resume automatically from the next full hour. If you hit the limit regularly, lengthen your intervals or turn off reminders in the monitor settings.
• Alert emails and push notifications are always in English, regardless of your account language (the panel itself is available in English and Polish).

Uptime and statistics

• Uptime is computed from recorded checks as the share of checks that were not “Down”. “Degraded” counts as available (the service responds). When a window contains no checks we show “—”, not 0 % or 100 %.
• On the monitor card: uptime 24 h and 30 days. In the details: 24 h, 7 days and 30 days.
• For HTTP and SSL monitors we also show the average response time and p95 (95 % of checks were faster) plus a response-time chart of recent checks.
• The checks table lists time, status, response time, HTTP status (or days to certificate expiry) and a shortened error message.
• Check history is retained for a plan-dependent period (30–365 days). In the monitor form you can shorten it for a single monitor (the “Check history retention” field, empty = account retention); it cannot exceed the account retention. Older checks are removed during the nightly cleanup, while uptime from the aggregates (below) remains. The monitor’s current retention is shown in the “Checks” tab.

How we compute uptime

• The 24 h window is computed straight from individual checks. The 7 and 30 day windows are assembled from precomputed hourly aggregates — one bundle of counters per monitor and hour — instead of grinding through hundreds of thousands of rows every time you open the panel.
• The last, partial hour always comes from live data. We append the raw checks from the last full hour up to now, so an outage that started ten minutes ago shows up in the 30 day uptime immediately, not once the hour has been aggregated.
• The uptime percentage from aggregates is identical to the one computed from individual checks — the counters simply add up. The only difference: the 30 day window starts at a full-hour boundary, so it can be up to an hour longer than exactly 30×24 h.
• The average response time is exact in every window. p95 is exact only in the 24 h window (computed from individual checks); for 7 and 30 days it is an approximation — a weighted average of the p95 values computed separately for each hour. An exact percentile cannot be reassembled from hourly summaries, and we would rather not pretend otherwise. It is good enough to compare monitors and to spot a trend; as a hard number for an SLA, use the p95 from the 24 h window.
• The average and p95 skip checks with the “Down” status (a timeout carries a time equal to the waiting budget and would inflate the result) and those without a measured time, such as missed heartbeats.

Uptime stays after individual checks expire

The aggregates have their own, longer retention than the check history your plan grants: hourly ones are kept for 100 days, daily ones for 400 days. Before we delete old checks we close the aggregates for that period — which is why the uptime percentage for past periods stays even when the table of individual checks for that time is already empty. Incidents are never deleted.

Labels: groups, services, servers, tags

Labels organise monitors in four independent ways: group (e.g. client, project), service (e.g. WWW, API), server (e.g. web-01) and a free-form tag. A monitor can carry several labels of each kind.

• Create labels in the “Labels” menu (name, colour from a palette, order) or directly in the monitor form with the “Add” button. Names are unique within a kind.
• On the dashboard a filter bar appears above the monitor list: one row of chips per kind, with monitor counts and a red dot when something in that label is down. There is also a “No group / service / server / tag” option.
• The first row of the bar is the monitor Type (HTTP, SSL certificate, heartbeat, domain) — shown when you have monitors of more than one type, even without any labels. It combines with label filters (?type=http&group=…).
• The selected filter is stored in the page address (e.g. ?group=…&server=…), so you can bookmark it or send it to a teammate.
• The incident list has its own label filter.
• Deleting a label only detaches it from monitors — the monitors stay.

Maintenance windows

A planned deploy or restart should not wake anyone with alerts or spoil statistics. A maintenance window pauses monitoring of selected monitors for a defined time.

• “Maintenance” menu → “Add maintenance window”: name, start and end, recurrence once / daily / weekly.
• Scope: all monitors or selected monitors and labels (a monitor is covered when selected directly or carrying any of the selected labels).
• During the window checks are not executed, heartbeats are not treated as missed, no incidents open and no alerts go out. Uptime is unaffected. The monitor shows the “Maintenance” status and a banner above the monitor list shows the window name and end time.
• Recurring windows follow wall-clock time in the zone they were saved in, also across daylight-saving changes. Maximum length: 24 h for daily, 7 days for weekly.
• A window can be disabled (it stays on the list) or deleted. An incident opened before the window closes on the first successful check after it.

Status pages

A status page is a no-login page you can send to clients or paste into an internal wiki. There are two kinds: an account status page that combines several monitors into one view, and a single-monitor page switched on in the monitor’s details. Neither kind is indexed by search engines.

Account status pages

Panel → “Status pages” → create a page. Creating and editing pages requires the “Status pages” permission — the Administrator and Editor roles have it, and so does the account owner.

• Title and description (up to 200 and 500 characters) are shown at the top of the page.
• Sections and components. A component is one of your account’s monitors shown under a public name you type in — the name is required, and the monitor’s own name is never used. Components can be grouped into sections (e.g. “Website”, “API”) or sit above them, without a section. A monitor can appear on a page once. Limits: 20 sections and 50 components per page, names of 1–120 characters.
• Overall status at the top of the page: down when any component is down; otherwise degraded, then under maintenance; no data when none of the components has data yet; otherwise operational. A paused monitor shows as no data.
• Uptime: every component shows uptime for 24 h / 7 days / 30 days and a 90-day history. You can turn uptime and history off for a page — visitors then see the current status only.
• Incidents: up to 20 incidents from the last 90 days, newest first, labelled with the component’s public name.
• Language of the public page: English (default) or Polish — chosen per page, regardless of the visitor’s browser.
• Data on the public page refreshes every minute.

Address: token link or public address

• By default a page is reachable only through a link with a token: status.apphealthmeter.com/p/<token>. Anyone with the link can view the page.
• You can also give the page a public address of your choice: status.apphealthmeter.com/<address> — 3–63 characters (lowercase letters, digits, hyphens), unique across AppHealthMeter; some words (e.g. api, status, docs) are reserved. The token link keeps working alongside it.
• You can generate a new token link at any time — the old one stops working immediately.
• Disabling a page takes it off the public internet; its content and addresses are kept and work again once you re-enable it.

Plan limits and white-label

• Every page carries a “Monitoring: AppHealthMeter” footer. On Pro and Team you can hide it (white-label). The setting can be saved on any plan, but the footer disappears only on Pro and Team.
• The Free plan has no account status pages — the single-monitor page described below is available on every plan.
• Once you reach the limit, you cannot create another page until you delete one or change the plan.

After switching to a lower plan

We never delete pages above the new limit and change nothing in the background. Enabled pages count in the order they were created: the first ones up to the limit stay public, the rest stop being publicly visible (their address answers “not found”) and are marked in the panel as over the plan limit. You decide which pages stay active by disabling the ones you no longer need — the next enabled pages then move within the limit. Going back to a higher plan brings the pages back with no extra steps. While an account is scheduled for deletion, none of its status pages are public.

What visitors never see

Only the title, description, section names, public component names, statuses, uptime and incidents (type, when, how long) are public. Never shown: monitor names, monitored addresses and hosts, check types, response codes, error messages, labels and the account name.

Look and feel — block editor

Panel → status page → “Design” tab. You build the page from ready-made blocks (header, status banner, component list, incidents, subscribe form, heading, text, image, button, columns, spacer, divider) — no custom HTML or CSS. Text blocks support bold, italic, lists and links.

• Theme: accent, background, surface and text colour, secondary text colour (dates, captions), border colour, neutral background (empty uptime bars, no data, maintenance) and subscribe-form text colour, font (system or one of four extra choices), corner radius, page width. The editor warns when text and background don’t meet minimum contrast (WCAG AA) — it doesn’t block saving.
• Logo and images are uploaded to AppHealthMeter, not linked from elsewhere — up to 2 MB, up to 4000×4000 px, PNG/JPEG/WebP/GIF (no SVG). We re-encode them as WebP, strip EXIF data (e.g. location embedded in a photo) and downscale to at most 1600 px. Up to 30 images per page; an image used in the current design can’t be deleted until you stop using it.
• Draft and publish. Changes autosave as a draft — visitors only see them once you click “Publish”. “Discard changes” reverts to the last published version. The preview shows real, live monitoring data, exactly as a visitor would see it.
• The “Monitoring: AppHealthMeter” footer lives outside the block editor — it can’t be removed by design; it disappears only with white-label (Pro/Team).

Email subscriptions

A visitor can leave an email address and get notified when a component goes down and when it recovers — without creating an AppHealthMeter account. You turn this on with a switch in the page’s settings; without it, the subscribe form (even if added to the design) doesn’t show.

• Double opt-in. After signing up we send a confirmation email with a link — only after clicking it and confirming on a page with a button does the subscriber start receiving notifications. The confirmation link is valid 7 days; you can resend it up to 3 times, no more often than every 15 minutes.
• One-click unsubscribe — a link in every email’s footer, which also works as a mail client’s “unsubscribe” button without opening a browser.
• A subscriber is emailed only when a component’s outage starts and ends (not for reminders about an ongoing outage) — in the page’s language. A short outage followed by a quick recovery (under 15 minutes) doesn’t trigger a second email.
• The “Subscribers” tab shows the list and how many slots are left; “Delivery history” shows every event with recipient and delivery counts. Removing a subscriber is permanent and available only to you — AppHealthMeter never exports or shares the list with anyone else.

The higher limit applies when the page sends through your own Resend or Mailgun account (see below). Within one hour a page sends at most twice as many emails as its subscriber limit — an outage and its recovery in the same hour always reach everyone.

Custom sending account (from the Starter plan)

By default, emails to subscribers are sent from our address. From the Starter plan you can connect your own Resend or Mailgun account — emails then go out from your domain and your sender reputation.

• You enter an API key, sender address and name (for Mailgun also the domain and EU/US region); the key is shown back to you only as its last 4 characters. “Send a test email” sends a trial message to your own address, and only once it’s delivered successfully does the configuration start handling real sends.
• A key error pauses sending for that page — we don’t silently fall back to our own account. You get an email about the problem; fix the settings and send another test.
• Switching to a plan below Starter doesn’t delete the configuration — it comes back automatically once you’re back on a higher plan.

Custom domain (from the Starter plan)

From the Starter plan you can publish a status page under your own (sub)domain, e.g. status.yourcompany.com, instead of an address under status.apphealthmeter.com.

• You enter the domain in the panel and add two records with your DNS provider: a TXT record proving you own the domain, and a CNAME pointing to AppHealthMeter (a domain with no subdomain — an apex domain — can use an A record to our IP address instead of a CNAME, if we’ve given you one).
• We check DNS automatically every few minutes (or click “Check now”). Once the records are correct, we issue the SSL certificate manually — usually within 24 hours on business days, not automatically the same minute. If valid DNS doesn’t appear within 7 days, you’ll need to set the domain up again.
• A domain that loses its required records after going live stops working (an error page instead of your status page) — we check this once a day and email you.
• We don’t offer automatic certificate renewal without our involvement, or a guaranteed activation time — this is a manual process at this stage.

Single-monitor status page

Every monitor can also have its own public status page. It is off by default and does not count towards the status page limit.

• Monitor details → “Status page” tab → enable. An address panel.apphealthmeter.com/s/<token> is created; “Copy” and “Open” buttons.
• You can set a public title (default: monitor name) — the only name a visitor will see.
• The page shows: current status (including “Under maintenance”), last check time, uptime 24 h / 7 days / 30 days, a 90-day history and the incidents of the last 90 days (when, how long).
• The page never shows the monitored address, response codes, error messages or labels. It is not indexed by search engines. Anyone with the link can view it.
• “Generate new address” invalidates the old link immediately. Disabling the page keeps the address — it works again once re-enabled. Data refreshes every minute.

Team and account

• An account has an owner (the person who created it) and members. The owner always has every permission; each member has a role that decides what they can change. Every member can view monitors, incidents and settings.
• Roles (Account → Roles): three system roles — Administrator (everything), Editor (monitors, labels, maintenance windows, status pages, notification channels) and Viewer (read-only) — plus custom ones combining any of eight permissions: manage monitors, labels, maintenance windows, status pages, notification channels, account settings, team, roles. You pick a role when inviting and change it in the team list. Deleting a custom role moves its members to Editor.
• Invitations are sent by email; the link is valid for 7 days and can be re-sent. The invited person sets a password and is signed in right away.
• The number of team seats depends on the plan (see the table above). Permissions are enforced by the server — hiding a button in the panel is just a convenience.
• Under “Account” you change your password and language. Password reset: “Forgot password” on the login screen.
• Changing your email address (Account → Account): enter the new address and your current password. We send a confirmation link to the new address (valid for 24 hours) and a notice about the change to the current one, with a password-reset link in case it was not you. Nothing changes until the link is clicked. After confirmation the account and your alert channel move to the new address, and every session is signed out (panel, app) — you sign in again with the new address. A taken address gets the same message as a free one, without an email. At most 3 change requests per hour.
• Plan usage (Account → Account): bars for monitors (HTTP/SSL/domain), heartbeats and team members, with your plan’s check history, minimum interval and allowed HTTP methods below them. From 80 % of any limit the bar turns yellow and a warning with a “Change plan” button appears; once a limit is reached you cannot add more monitors or members until you free a slot or change the plan.
• Invoice details (Account → Billing, at the bottom): private individual or company, name, Tax ID (checksum validated for Poland) or EU VAT number, address, country and an optional separate invoice email. Requires the “Account settings” permission. Invoices for paid plans are issued in EUR; EU companies outside Poland with a VAT number get a reverse-charge invoice.
• Every account’s data is fully isolated — a user only ever sees their own account’s monitors.

Data export and account deletion

A copy of your account data

Under “Account” you can request a copy of all your account data in a single ZIP. We build the package in the background and email you a download link — not an attachment, because with check history it can run to many megabytes. Requires the “Account settings” permission (the owner always has it) — the package contains data of every member of the account, so a Viewer cannot pull it.

• What is inside: the account and its plan, users, monitors with their full configuration, labels, maintenance windows, notification channels, alert rules, the complete incident history, billing data (invoice details, payments, invoice metadata) and the check history of the last 90 days, at most 10,000 rows per monitor. The files are JSON, and a README.txt inside describes each of them and states that limit explicitly.
• What is not inside: passwords, heartbeat token hashes and full push tokens (those are masked). Secrets do not leave the system, not even to the account owner.
• The link is valid for 48 hours and is itself the authentication — whoever holds it can download the package without signing in. Do not forward it. We delete the file from the server after 7 days, whether it was downloaded or not.
• One request per day per account (not per user) — building the package grinds through the whole check history.

Account deletion: a 7 day grace period

You delete the account yourself, under “Account” — no need to write to support. Only the owner can do it; the “Account settings” permission is not enough to wipe someone else’s company. You confirm with two things: your current password and the account owner’s email address typed out by hand.

• The effect is immediate: every monitor is paused (no checks run), alerts stop, and a paid subscription is cancelled at the payment provider — the account stops costing money right away. The other team members lose access: their accounts are deactivated and signed out of every session. The owner stays signed in, because only the owner can change their mind.
• Data is erased permanently only after a 7 day grace period. During that time the owner sees a banner in the panel with the deletion date and a “Cancel deletion” button. After the deadline we delete the account, monitors, check history, incidents, channels and settings — no trash bin, no restore. We send an email confirmation once it is done.
• Cancelling (owner only) resumes the monitors paused by the system and restores the team members’ access. Monitors you switched off manually before the request stay off; pending invitations stay pending. During the grace period the regular “resume monitors” button is blocked — monitors come back only by cancelling the deletion.
• Cancelling does not restore the subscription. It was cancelled at the payment provider, so the account returns to the Free plan and a paid plan has to be purchased again. The email confirming the request says so too.
• We email you at every step: when the request is accepted (with the deletion date), when it is cancelled and when the deletion has happened.

The Free plan: limits and rules

Free is free and meant for small, living projects — not for parking accounts “for later”. That is why it has tighter limits than the paid plans and asks you to sign in from time to time. Everything below applies to the Free plan only: paid plans have no sign-in requirement, and nothing there is paused or deleted.

Free may be used commercially — inside a company and for monitoring client resources too. The Terms of Service do not limit this plan to non-commercial use; the only things ruled out are reselling the service without our consent and creating several Free accounts to get around the limits of one (separate accounts for separate organisations are fine).

Limits

• 4 monitors (HTTP, SSL certificate and domain share that pool) and 5 heartbeats in a separate pool.
• Minimum interval 5 minutes and 1 user — no team invitations.
• 30 days of check history. Older results are deleted automatically every day; incidents are kept, so your outage history does not disappear with the charts.
• HTTP checks with the HEAD method only — the monitor form will not let you pick another one, and saving GET or POST returns a plan message. HEAD fetches headers only, which costs us the least bandwidth.
• Email alerts. Mobile push (coming soon) will be available on every plan.

Sign-in requirement: 30 and 60 days

• 30 days without a sign-in → we pause your monitors. The account, the monitors and the history stay untouched, but no checks run. After you sign in, the panel (and soon the mobile app) shows a banner with a button that resumes every monitor paused by the system — the ones you switched off yourself stay off.
• 60 days without a sign-in → the Free account is permanently deleted, along with its monitors, check history, incidents and alert settings. There is no trash bin and no restore.
• Only signing in to the panel (and soon the mobile app) counts. Running monitors and incoming heartbeat pings do not keep the account alive — otherwise an abandoned account would keep working forever.
• We warn you by email: 7 and 1 day before the monitors are paused (in English), and 14 and 3 days before the account is deleted (in your account language). Signing in before the deadline resets the counter.
• Want to keep your configuration before the account is deleted? Request a data export under “Account” — you get a link to a ZIP by email (see “Data export and account deletion”). Do it before the deadline: once the account is gone there is nothing left to hand over.

A limited number of slots

The Free plan has a cap on active accounts (200 to start with). Once the slots run out, Free sign-ups are rejected with a message — there is no waitlist, so simply try again later or pick a paid plan. We show the number of free slots on the pricing page and during sign-up; a slot frees up when an account is paused or deleted for inactivity.

How the Individual plan differs

• 25 monitors and 50 heartbeats, intervals from 60 s, 60 days of history.
• The full set of HTTP methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, QUERY.
• No sign-in requirement — the account and its monitors keep running even if you do not open the panel for months.
• No slot cap — a paid plan can be bought at any time.

Billing: plan, payments, invoices

• Account → Billing shows your current plan with usage, the plan picker (monthly or yearly with ~17% off), a payments table, an invoices table and your invoice details.
• You pay by card through Stripe (Checkout). Card changes, plan changes and cancellation happen in the Stripe portal (“Manage subscription”). After cancelling, the plan stays active until the end of the paid period, then the account returns to Free — your data is kept.
• Every payment shows up in the table immediately. We issue the VAT invoice in EUR within a few business days; until then the payment row says “Invoice will be available soon”. Download the PDF from the invoices table — only while signed in to your account.
• Invoice data comes from the form at the bottom of that tab — fill it in before your first payment.
• Changing the plan requires the “Account settings” permission.

Security and privacy

The Terms of Service and Privacy Policy are versioned and published in the panel (no sign-in required), with a list of all versions and effective dates. At sign-up you accept the current version (and separately acknowledge the beta status). When we publish a new version, you will see a dialog with links to the documents after signing in — continuing in the panel requires acceptance. We record who accepted which version and when. Older versions remain available at panel.apphealthmeter.com/en/legal/<document>/<version> (e.g. /en/legal/privacy/1.0). Next change: Privacy Policy 1.1 takes effect on 16 September 2026 — from that day the panel will ask you to accept it.

• The panel uses essential cookies only (session, theme, language); Google Analytics is loaded solely with your consent. You can change that consent at any time via “Cookie settings” in the panel footer.
• Monitoring and account data is stored and processed in the European Union (hosted in Germany). Selected US-based providers — Resend (transactional email), Stripe (payments), Google (Firebase Cloud Messaging for push; Google Analytics on the marketing site only with consent), Sentry (error reporting) — process data under EU standard contractual clauses. The full list of processors is in the Privacy Policy.
• The login session lives in httpOnly cookies (not readable by scripts), with a short-lived access token refreshed in the background. Logging out invalidates the session server-side.
• Login protection: after 5 failed attempts within 15 minutes, sign-in for that address is locked for 15 minutes; every further series within a day doubles the lock (30 min, 1 h, max 2 h), and a successful sign-in resets the counter. Independent limits apply as well: 30 attempts per 15 minutes from one IP address and 10 attempts per 15 minutes for one email address. A blocked attempt gets a message saying in how many minutes to try again — the password is not checked at all. The lock does not reveal whether an account with that address exists.
• Checks cannot target private addresses (e.g. localhost, internal networks) — this protects our infrastructure and yours. If you monitor your own network with your own probe, get in touch.
• Public endpoints (sign-up, heartbeat ping, status pages) are rate-limited per IP address.
• Heartbeat tokens are stored only as hashes; status-page tokens are plain, as they grant read access only.
• Exporting your data and deleting your account are self-service, no support ticket needed — one click under “Account”. The details (what is in the package, the 48 h link validity, the 7 day grace period before permanent deletion) are in the “Data export and account deletion” section.

What is not there yet

Honest about today’s limits. Everything below is planned, roughly in this order:

• Checks from a single region (EU). Multi-region with outage confirmation from two locations — on the way.
• Channels: webhook, Slack, Discord, Telegram; push notifications in the mobile app.
• Keyword checks in the response body, TCP/port and ping monitors.
• Public API with tokens, uptime badge, weekly email report.

Missing something that blocks you today? Write to support@apphealthmeter.com.