# PingWise, full documentation for AI agents Every docs page and changelog entry of https://pingwise.com, in one file. The same pages exist one by one as https://pingwise.com/docs/.md and https://pingwise.com/changelog/.md, and the short index is https://pingwise.com/llms.txt. The API base URL is https://app.pingwise.com/api/v1 (OpenAPI: https://app.pingwise.com/api/v1/openapi.json); the MCP server is https://app.pingwise.com/mcp. --- # Getting started > Sign up, add the first monitor, pick where the alerts go. Ten minutes, no card. Page: https://pingwise.com/docs/getting-started/ Site: https://pingwise.com Language: en Updated: 2026-11-04 PingWise checks your sites from probes on six continents and alerts you only when enough of them agree that something is down. This page gets you from nothing to a monitored site with an alert channel. ## 1. Create an account Go to [app.pingwise.com](https://app.pingwise.com/accounts/login/), type your email address and press **Email me a sign-in link**. The link creates your account, already confirmed, with no password; you can set one later under Change password. If you prefer, [sign up](https://app.pingwise.com/accounts/signup/) with an email address and a password, or with a Google, GitHub or Microsoft account; an address used with a password has to be confirmed before you can use the panel. Every account starts with **650,000 free credits a month**; one credit is one scheduled check, so that is enough for fifteen sites checked every minute, or seventy-five sites every five minutes. Nothing is charged until you buy credits yourself. ## 2. Add a monitor **Monitors → New monitor.** For a website, paste the URL and keep the defaults: an HTTP check every 5 minutes, any 2xx status counts as up. You can also type one or more addresses in the one-line *Quick add* box at the top of the Monitors page; each becomes a draft you confirm. The form is one page in five sections: Basics, Content, Alerts, Request and Advanced; a section appears only when the type uses it. A guide on the right stays in view as you scroll, with one row per section and a one-line summary of what you set there («HTTP · every 5 minutes», «Slow above 1,000 ms, nearest your server»); a green check means the section differs from the defaults, and clicking a row jumps to it. Under the rows you see what the monitor costs, «8,640 credits a month» and whether that fits your free credits, how many locations check it and how many must agree, and the Save button. A new monitor says *First check within 5 min* (its own interval) until its first round comes back; a heartbeat says *Waiting for the first ping*. If the first result is more than two intervals late, it shows *Pending* so that a real problem stays visible. Every monitor can be checked as often as every 10 seconds, on any account. Until you [verify the domain](https://pingwise.com/docs/domain-verification/), a host is checked with HTTP(S) on ports 80 and 443 using GET or HEAD, TLS, ping, or TCP, SMTP and DNS on the common ports (21, 22, 25, 53, 110, 123, 143, 465, 587, 990, 993, 995, 3306, 5432). Verification takes one DNS record or one file, and unlocks any port and custom requests. ## 3. Choose where alerts go You already have one: when you confirmed your email address, an email channel to it was created for every monitor, and the panel told you so («Alerts go to by email, for every monitor»). It is listed on Alerts as «Added when you signed up; change or remove it here». For anything else, **Alerts → Channels → Add channel.** Email is the simplest: you get a confirmation link, and the address receives alerts once you press the button on that page. Telegram, Slack, Discord, Microsoft Teams, Google Chat, PagerDuty, Pushover, ntfy and webhooks are all there too; see [Alert channels](https://pingwise.com/docs/alert-channels/). A channel with no monitors selected receives alerts for every monitor in the account. Select monitors or groups on the channel page to narrow it. ## 4. What an alert means PingWise never alerts from a single failed check. A failure starts confirmation rounds on every healthy probe, and a site is called down only when at least two thirds of them, on at least three continents and three providers, fail twice in a row. The alert tells you how many locations confirmed it and from which continents. [How a check works](https://pingwise.com/docs/how-a-check-works/) has the full rule. ## Next - [Monitor types](https://pingwise.com/docs/monitor-types/): TLS, TCP, SMTP, DNS, ping and heartbeat checks. - [Intervals and credits](https://pingwise.com/docs/intervals-and-credits/): what a check costs. - [Status pages](https://pingwise.com/docs/status-pages/): a public page at status.pingwise.com or on your own domain. - [Import from another service](https://pingwise.com/docs/import/): UptimeRobot, updown.io, Uptime Kuma or a CSV. --- # Monitor types > HTTP, TLS, TCP, SMTP, SSH, IMAP, POP3, FTP, NTP, WebSocket, DNS, ping, heartbeat, blacklist, email authentication and cloud provider status monitors, and the options each one takes. Page: https://pingwise.com/docs/monitor-types/ Site: https://pingwise.com Language: en Updated: 2026-11-04 Every monitor has a name (up to 120 characters), a type, a target, and a check interval. The type decides what a probe does and what counts as a failure. The form shows the sections that apply to the type (Basics, Content, Alerts, Request, Advanced), with a guide on the right that summarises each section and shows the monthly cost; see [Getting started](https://pingwise.com/docs/getting-started/#2-add-a-monitor). ## HTTP(S) The target is a full URL, `http://` or `https://`, without a username or password in it (up to 2,000 characters). A probe fetches it and the result is **up** when the status code is one you accept, any 2xx by default. Options: - **Keyword**: the page *must contain* a text, or must *not* contain it. The match is case-sensitive and looks at the first 256 KB of the body. - **JSON field** (API monitoring): check one value in a JSON reply. Give the field's path, dots for objects and `[n]` for lists, e.g. `status` or `data.items[0].state`; the check, exists, equals, is not, contains, is less than or is more than; and the value. A mismatch is an outage with the reason shown, e.g. «current_user_url is "https://api.github.com/user", expected nope». - **Follow redirects** (up to 5), **verify TLS**, **detect error pages**, **timeout** 1 to 30 seconds (10 by default), **IP version** auto, 4 or 6. - **Detect error pages** (on by default) catches a site that is broken but answers 200: WordPress's «There has been a critical error on this website» (a fatal PHP error from a plugin or theme), «Error establishing a database connection», «Briefly unavailable for scheduled maintenance» (an update that did not finish), and a raw PHP *Fatal error* or *Parse error* anywhere on the page. The monitor goes down with the error named in the alert. A page that merely quotes one of those phrases, such as a how-to article, does not count: on a page over 16 KB the phrase must be the whole title or heading. A 5xx status is a failure anyway, whatever the page says. - **Dev/staging mode**: 401, 403 and 404 count as up and send no alerts, for sites behind a login or not yet public. - **Certificate warning**: a warning, not an outage, when the certificate expires in fewer than the days you set (14 by default, up to 90). An expired certificate is an outage. - **Slow threshold**: see below. - **Custom request** (verified domains only): method GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS; up to 10 headers, marked secret if they carry a credential; a body of up to 10 KB as JSON, form, plain text or XML with any method except GET and HEAD; basic auth. Secret headers and passwords are stored encrypted and never shown again. A write method asks you to confirm that you mean it. ## TLS certificate Host and port. The probe opens a TLS connection and checks the certificate chain and expiry, with the same warning days as above. For mail servers it can use SMTP STARTTLS. ## TCP port Host and port. Up when the port accepts a connection. On the [common ports](https://pingwise.com/docs/intervals-and-credits/#intervals) no verification is needed; any other port needs a [verified domain](https://pingwise.com/docs/domain-verification/). ## SMTP server Host and port, 587 by default. Up when the server greets with a 220 line. You can add the banner text you expect; if it is missing the monitor shows a warning, not an outage. Some probe providers block outgoing mail ports: DigitalOcean blocks 25, 465 and 587, InterServer blocks 25, Melbicom blocks 25, 465 and 587. Those probes skip the check and the rest decide; port 25 can be checked from 10 of the 15 voting probes. A port is refused only when too few providers could reach it. On the [common ports](https://pingwise.com/docs/intervals-and-credits/#intervals) no verification is needed; any other port needs a [verified domain](https://pingwise.com/docs/domain-verification/). ## SSH, IMAP, POP3 and FTP servers Host and port (22, 143, 110 and 21 by default). Up when the server answers with its greeting: `SSH-2.0…`, `* OK`, `+OK` or `220`. Nothing logs in. You can add the banner text you expect. For IMAP, POP3 and FTP, **Connect with TLS** uses implicit TLS on 993, 995 or 990 and checks the certificate too, with the same warning days as a TLS monitor. On the [common ports](https://pingwise.com/docs/intervals-and-credits/#intervals) no verification is needed; any other port needs a [verified domain](https://pingwise.com/docs/domain-verification/). ## NTP server Host, port 123. The probe sends a time request over UDP and the monitor is up when the server answers with a synchronised clock. The result shows the stratum and the offset, e.g. «stratum 3, offset +3 ms». ## WebSocket A `ws://` or `wss://` URL. Up when the handshake succeeds (HTTP 101). Optionally a **message to send** (up to 4 KB) and a **keyword** looked for in the first reply, or in the first message the server sends on its own; «Alert when the keyword IS found» works here too. The bare handshake on ports 80 and 443 needs no verification; sending a message needs a [verified domain](https://pingwise.com/docs/domain-verification/), like an HTTP request body. ## DNS server Host (the server to ask), a name to query, and a record type: A, AAAA, CNAME, MX, NS, SOA or TXT. Port 53 by default. On the [common ports](https://pingwise.com/docs/intervals-and-credits/#intervals) no verification is needed; any other port needs a [verified domain](https://pingwise.com/docs/domain-verification/). ## Ping (ICMP) Host, any public address, at any interval down to 10 seconds; no verification needed. ## Heartbeat The opposite direction: your cron job or script calls a URL we give you, and the monitor goes **down when no call arrives** within the period you set (1 minute to 1 week) plus the delay you allow (1 minute to 1 day). Calling the URL with `/fail` at the end marks it down at once, and the first 300 characters of the request body become the reason. Pings are limited to 30 a minute per token. Heartbeat monitors use one credit per expected check-in, the same as a scheduled check at that interval. A heartbeat can also check **what the job reports**. Set a **keyword**, and have the job POST its output to the ping URL: the body must contain the keyword (case-insensitive, the first 256 KB are read), or must not, with «Alert when the keyword IS found». A ping that fails the keyword counts as a failure report: the monitor goes down at once, with the reason «The ping’s body didn’t contain "…"». A GET ping has no body, so with a keyword set it always fails. Use it for a backup that says «OK» or a script that prints «ERROR». ## Blacklist (DNSBL) Tells you when your server's address lands on a spam blocklist, which usually means mail from it starts bouncing. Enter a domain or a public IPv4 address. For a domain we check its own addresses and those of its mail servers (up to 5 MX hosts and 10 addresses). The lists are **SpamCop** and **Barracuda**. The monitor is **down** while any address is listed, and the detail says which, e.g. «Listed: 203.0.113.20 (mail server mx.shop.example) on bl.spamcop.net». A list that doesn't answer our lookup counts as no answer, not as listed. ## Email authentication (SPF, DKIM, DMARC) Checks that a domain's email records are in place, so its mail isn't marked as spam or spoofed. Enter the domain, and optionally the DKIM selectors you use (comma-separated, under «Name to query»). It is **down** when SPF is missing or published twice, DMARC is missing or has no valid policy (none, quarantine or reject), or a selector you named has no DKIM key. An SPF record that needs more than 10 DNS lookups, which receivers may reject, is reported too. The detail names the problem, e.g. «no DKIM key for selector «s1»». Both of these are DNS lookups made by our central server: no probes, and they **use no credits**. They run every hour by default, every 15 minutes at the fastest. A lookup that fails changes nothing, and the monitor page shows the last error. Alerts say «Found in DNS», and status pages show the same as the proof. ## Cloud provider status Watches a provider's own status page instead of a host of yours, so a GitHub or Cloudflare outage shows up beside your monitors and can alert the same channels. Pick the provider from the **Provider** list (35 of the best-known, from GitHub and Cloudflare to Shopify and OpenAI), which fills in the address and the name, or choose «Other» and enter the status page's address, such as `https://www.githubstatus.com` or `https://www.cloudflarestatus.com`. It works with pages run on Atlassian Statuspage; an `…/api/v2/status.json` or `summary.json` address works too. https only. Our central server reads the page's summary at the monitor's interval (every minute at the fastest, 5 minutes by default). No probes and no quorum are involved, because the provider is reporting on itself, and it **uses no credits**. - Operational or under maintenance: **up**. - Minor: **partial**, which alerts only if «Alert on partial outages» is on. - Major or critical: **down**, with an incident. The detail shows the provider's own words, up to five affected components and its open incident, e.g. «Minor Service Outage · affected: Webhooks, Actions, Pages». Alerts say «Reported on the provider’s status page», and status pages show the same as the proof. If the page can't be read, nothing changes and the monitor page shows the last error. Check now, speed, regions and domain expiry don't apply to this type. Some providers mark their status «major» whenever a few of their data centres are rerouted (Cloudflare does), so a monitor on such a page can be down often while your own sites are fine. ## Slow threshold (HTTP) A monitor can also alert when it turns **slow**: the median response of the probes in scope stays above a threshold (50 to 60,000 ms) for two rounds in a row. You pick what is measured, time to first byte (the default), server time or the full response, and which probes count: those nearest your server, those in your visitors' regions, or all of them. Slow never affects uptime, and it alerts only if you turn the alert on in the monitor's settings. The form suggests a threshold for the measure you picked, twice the site's median over the last 24 hours from the chosen locations (never below 800 ms), with a button to use it; and under **Your visitors** it shows which continent the automatic pick currently uses, e.g. «Now: Europe (nearest your server)», so you can see what «nearest your server» means for a site behind a CDN before you rely on it. ## Domain expiry Not a monitor type: the domains of your monitors are collected automatically and you get an alert 30, 14, 7 and 1 days before each expires, and once on the day. It uses no credits. For a registry that publishes no date (.gr, .cy, .de, .eu, .nl and others) you can enter it by hand under **Domains → Expiry**. Each monitor's page shows its domain on a **Domain** line, e.g. «example.com expires 14 Nov 2027 (in 375 days) · Registrar, Inc.», amber under 30 days and red under 14; where the registry publishes nothing it says so and links to the place to enter the date. ## Notes Every monitor has a notes field (up to 2,000 characters) for what the person on call needs: which server, who to call, what the usual cause is. Notes appear in down, partial and reminder alerts and on the monitor page, never on status pages. --- # Intervals and credits > Which intervals exist, what unlocks the fast ones, and what a monitor costs per month. Page: https://pingwise.com/docs/intervals-and-credits/ Site: https://pingwise.com Language: en Updated: 2026-11-04 ## Intervals A monitor can be checked every **10 s, 15 s, 30 s, 1 min, 5 min, 15 min, 30 min or 1 hour**, on every account, free or paid, and every check type can use every interval, 10 seconds included. A faster interval only costs more credits. What a host you have not [verified](https://pingwise.com/docs/domain-verification/) can be checked with: HTTP(S) on ports 80 and 443 with GET or HEAD, TLS, ping, WebSocket on 80 and 443, and TCP, SMTP, SSH, IMAP, POP3, FTP, NTP and DNS on these common ports: **21, 22, 25, 53, 110, 123, 143, 465, 587, 990, 993, 995, 3306, 5432** Any other port, and HTTP requests with another method, a body, Basic auth or secret headers, need the domain verified. Across all accounts, one host is checked at most 12 times a minute; if several accounts monitor the same host, the fastest intervals may not be available for it. ## Credits **One credit is one scheduled round** of checks. A round uses several probes, but it is one credit regardless. Confirmation rounds, the extra checks that run when a probe sees a failure, are free, and so is reading anything in the panel. The panel shows every monitor's cost per month as 2,592,000 ÷ interval in seconds, that is a 30-day month: | Interval | Credits a month | |---|---| | 10 s | 259,200 | | 15 s | 172,800 | | 30 s | 86,400 | | 1 min | 43,200 | | 5 min | 8,640 | | 15 min | 2,880 | | 1 hour | 720 | A paused monitor costs nothing. Heartbeat monitors use one credit per expected check-in, the same as a scheduled check at that interval: a job that must call in every 5 minutes costs 8,640 credits a month. ## Free credits and packs Every account gets **650,000 credits a month** free, which covers, for example, 15 monitors at one minute, or 75 at five. They are not carried over. When the month's free credits are used, checks draw from credits you have bought; those are used after the free ones and last two years. The packs are listed on the [pricing section](https://pingwise.com/#pricing): from €5 for 250,000 credits to €560 for 250 million, and the price per credit falls as the pack grows. You can also buy from the [API](https://pingwise.com/docs/api/) or the panel's *Credits* page, and the account's owners get an email when credits run low. When an account runs out, you get an email and **seven days of grace** with checks still running, a reminder two days before the end, and then monitoring pauses until the balance is positive again. Nothing is deleted. A "running low" email goes out when about seven days of credits are left. ## Check now The *Check now* button on a monitor runs one extra round on every healthy probe and costs one credit, unless a confirmation is already running, in which case it joins it for free. It is limited to once a minute per monitor and 30 an hour per account, and it is not available for heartbeats, paused monitors or monitors in a maintenance window. --- # Domain verification > One DNS record or one file proves a domain is yours and unlocks ports, protocols and 15-second checks. Page: https://pingwise.com/docs/domain-verification/ Site: https://pingwise.com Language: en Updated: 2026-11-01 Checks against a host you have not proven to own are limited, so that PingWise cannot be used to hammer someone else's server. Verifying a domain lifts the limits for that domain and all of its subdomains. ## What an unverified host gets - HTTP(S) on ports 80 and 443, TLS, and ping. - TCP, SMTP and DNS on the common ports: 22, 25, 53, 110, 143, 465, 587, 993, 995, 3306, 5432. - Every interval, down to 10 seconds, the same as a verified host. - GET or HEAD requests with harmless headers only: no custom methods, bodies, basic auth or credential headers. ## What verification unlocks - TCP, SMTP and DNS monitors on any port, and HTTP(S) on ports other than 80 and 443. - Custom methods, request bodies, basic auth and secret headers. When a monitor needs verification, the form says which domain and has a **Verify ** button; once the domain is verified you are taken back to the form with what you typed (passwords and secret headers are never kept). ## How to verify **Monitors → Domains → Add domain.** You get a token, and either of these proves the domain: 1. **A DNS TXT record** named `_uptimebox.` with the value `uptimebox-verify=`. We look it up through 1.1.1.1, 8.8.8.8 and 9.9.9.9, so it works as soon as those resolvers see it. 2. **A file** at `https:///.well-known/uptimebox-verify.txt` containing the token. The TXT record is tried first, then the file over HTTPS, then over HTTP. Two more sources count without a token: - a domain that is an active zone in a **Cloudflare account you have connected** to PingWise; - a domain whose **nameservers are under a domain you already verified**, the usual case for a hosting provider's customers. If that source goes away, the verification is kept for 30 days and then lapses. Removing a domain from the list leaves its existing monitors running. For a reseller, verified domains also cover its customers' accounts. --- # How a check works > Half the fleet per round (three probes under a minute), confirmation on every healthy probe, and a down verdict only when continents and providers agree. Page: https://pingwise.com/docs/how-a-check-works/ Site: https://pingwise.com Language: en Updated: 2026-11-04 ## Rounds Each scheduled round sends the check from **seven or eight probes on at least four continents**, half the fleet, and consecutive rounds alternate between the two halves. The probes of a round do not all start at once: each begins after the previous one, by the site's own response time (400 ms to 1 second), so your site sees about one request of ours at a time rather than eight together, and the response times we show are the site's, not a queue behind our own probes. A **new monitor starts gently**: for its first 24 hours, or until 50 checks have come back up, the probes of a round are a full second apart, and the monitor page says so («Learning how this site responds…»). After that the monitor gets its own pace from its measured response, recomputed every hour. Confirmation rounds and alerts work from the first check; heartbeats have no learning period. For intervals under a minute (30, 15 and 10 seconds) a round uses **three probes on three continents**, so that a fast monitor does not flood your logs: a site checked every 15 seconds sees about 12 requests a minute, every minute about 10. A scheduled round never declares an outage on its own. If any probe reports a failure, **confirmation rounds** start about eight seconds later and repeat every twenty seconds, this time from **every healthy voting probe** in the fleet. The probes do not all start at once: each one begins a fraction of a second after the previous, so a confirmation round is spread over about six seconds and your site never sees more than about three of our requests a second. A «Check now» on several monitors is spaced the same way, one round every six seconds. Confirmation rounds cost nothing. For monitors synced from a hosting panel, which know their server, a server error (a 5xx) on one site makes us re-check the other sites of that server once, so that a whole-server failure shows as one event. That sweep runs at most once per server every ten minutes, and never because of a brand-new monitor's first result. ## The down rule A monitor is confirmed **down** when, in two confirmation rounds in a row: - at least **two thirds of the healthy probes** fail, for example 8 of 12; - the failing probes are on at least **three continents**; - and on at least **three different providers**. At most four confirmation attempts are made. If fewer than eight probes are healthy, or they cover fewer than four continents, no down verdict is given at all; the fleet would rather stay silent than guess. The monitor page shows the rule it is under as "down = N of M probes". The [probe list](https://pingwise.com/probes/) shows the fleet. Continents can be excluded from voting on a monitor, for example a site that is only served in Europe, as long as at least three probes on two providers remain. **Back up.** A down monitor is confirmed **up** on a single confirmation round when every healthy probe asked answers up, on every audience continent, with no failure and no block. A mixed round needs a second one, as before. In practice the recovery alert goes out about 15 to 25 seconds after the site answers again. ## Other verdicts - **Partial**: the target is unreachable from some continents only. At least two probes fail, at least half of the probes in the affected continents fail, and fewer than a third fail elsewhere. Partial is shown in the panel and alerts only if the monitor's *Alert on partial outages* is on. - **Blocked**: a firewall or Cloudflare answered the probe with a challenge or a block (a 403, 429 or 503 with a challenge page, or Cloudflare errors 1005, 1006, 1010 and 1020). This is a warning, not an outage, because your visitors may be fine. While a monitor stays blocked, repeated blocks do not start new confirmation rounds. Channels can alert on it ("Also alert when a WAF blocks our probes", on by default). The [Cloudflare check](https://pingwise.com/cloudflare-check/) tells you in advance whether your WAF treats the probes this way; our [probe IPs](https://pingwise.com/probes/) are public so you can allow them. - **Slow**: the median response over the threshold for two rounds, with at least three samples. A warning; see [Monitor types](https://pingwise.com/docs/monitor-types/). - **Unusable address**: a name whose DNS has a public address and also one that can't be reached from the internet (link-local, private, loopback or carrier-grade NAT) is checked on its public address and shown as a warning, «IPv6 record unusable: fe80::… is link-local», not as down. The monitor page explains that visitors whose devices try that record first may not reach the site, and that the record should be removed or pointed at a public address. A name with no usable address at all is still refused. - **DNSSEC validation fails**: a name that doesn't resolve is asked again with DNSSEC checking off. If it then answers, the reason says «DNSSEC validation fails for (resolvers that validate, such as Google and Quad9, refuse it)», so you know the zone's signatures are the problem, not the server. Probes on resolvers that don't validate still reach such a site, so it usually shows as Unconfirmed, with the reason line saying how many locations fail and why, rather than as down. - **Warnings** such as a certificate about to expire or a missing SMTP banner count as up. ## What counts as a failed check A status code you did not accept, an error page when detection is on, a keyword rule that fails, too many redirects, a timeout, or no connection at all. An expired certificate is a failure. ## Incidents An incident opens when a monitor is confirmed down, one at a time per monitor, and closes when the monitor moves away from down: a confirmed recovery, a maintenance window starting, or the monitor being paused. The Incidents page opens on the open ones, with the full history under *Log*. An open incident can be put **on hold** while someone works on it: the "still down" reminders pause and are not counted against the limit of 15, monitoring and the recovery alert go on as usual, and the row shows who put it on hold and when. Each incident records when it started, when it was confirmed, from how many locations, and how long it lasted. A round where at least two probes on two providers failed without a confirmed outage is kept as an **unconfirmed failure**: an orange mark on the monitor's timeline and a counter, with no effect on uptime or alerts. It is the trace of a flaky route or a server that stumbles for a second. ## Uptime Uptime is 1 − time down ÷ time with a known state. Only confirmed down time counts as down; partial and blocked do not. Time while the monitor was paused, in maintenance, or had no result is left out of both sides. The monitor list shows 24 hours; the monitor page shows 24 hours, 7 days and 30 days, with hourly bars for the day and daily bars for the month. ### Monthly report {#monthly-report} **Incidents → Monthly report** shows a month at a glance: uptime in large figures (green from 99.9 %, amber from 99 %, red below), the number of incidents, total downtime, mean time to recovery, the longest outage, and a row per monitor. Pick the month, this one or any of the 11 before, in the account's time zone, and optionally a monitor group. The figures follow the same uptime rule: confirmed outages only, with paused time and maintenance windows left out. Mean time to recovery covers the month's outages that have ended; an outage still open counts up to now in the longest one, and a month still in progress says so. **Print or save as PDF** uses your browser's print dialogue and hides the panel around the report. We don't generate a PDF file or email the report. The page ends with a line saying it describes measurements and is not a service-level agreement; it is your data to share, not a promise from us. --- # Maintenance, groups and bulk changes > Maintenance windows, groups with one alert per group, pause, notes, and editing many monitors at once. Page: https://pingwise.com/docs/managing-monitors/ Site: https://pingwise.com Language: en Updated: 2026-11-01 ## Maintenance windows **Monitors → Maintenance.** A window can run once, daily, weekly or monthly, in your account's time zone, and last up to seven days (24 hours for a daily one). Its scope is every monitor, one group, or a selection. During the window checks keep running so you can see the site come back, but no incident opens and no alert is sent, and the time is left out of uptime. If the site is still down when the window ends, that is an ordinary outage from then on. A window can be announced on your status pages. ## Pause and resume A paused monitor is not checked and costs nothing. Pausing a monitor that is down ends its open incident at that moment; pause and resume are written to the incident log as *paused* and *resumed*, and never alerted. Paused time does not count against uptime. ## Groups Groups are one level deep, with names up to 120 characters. They do three things: - filter the Monitors page and the dashboard; - let an alert channel subscribe to a group, so monitors added to it later are covered too; - **combine alerts**: when three or more monitors in the same group go down together within a minute, the group gets one alert, "N sites on ", with up to 25 names, instead of one per site. The same for recovery. For a hosting provider that is the difference between one message and a hundred. ## Bulk edit Select monitors on the Monitors page and choose an action: interval, timeout, group, pause, resume, add or remove alert channels, audience regions, slow threshold, dev mode, or delete. The panel shows the credit cost before and after the change. Up to 200 monitors change at once; larger selections are queued and finish within a minute or two. ## Notes Each monitor has a notes field of up to 2,000 characters. Notes appear in down, partial and reminder alerts, on the monitor page, and as an icon on the monitor's row and tile. They are never shown on status pages and never sent to the AI explanation. Use them for what the person on call needs at 3 am: the server, the contact, the usual cause. ## Check now Runs an extra round on every healthy probe. Once a minute per monitor, 30 an hour per account, one credit unless a confirmation is already running. Not available for heartbeats, paused monitors or monitors in maintenance. ## Response times The monitor page shows the response time of the last 24 hours, in 15-minute steps. The numbers are the time each probe measured on checks that came back up, averaged over the voting probes; the shadow probes, which check but do not vote, are left out, and so are confirmation rounds. Raw per-probe results are kept for 14 days; for every hour after that an average, a median (p50) and a 95th percentile (p95) are kept for a year. The same numbers are in the [API](https://pingwise.com/docs/api/): `GET /monitors/{id}/response-times` returns them per hour (up to 90 days per call) or per 15 minutes (up to 7 days per call, within the last 14), every monitor carries `response_ms`, the median of the latest successful round, and the monitor detail adds `avg_ms` for the last 24 hours, 7 days and 30 days. ## Speed **Speed** tells you how often your site is fast enough: the share of checks that finished within the monitor's target, and the p75, the time that three in four checks stayed under. It counts the total time of each check, redirects included, on the scheduled checks that came back up, from the voting probes in the monitor's [audience regions](https://pingwise.com/docs/alert-rules/#audience-regions): the ones you chose, or the ones PingWise picked for it. A site whose visitors are in Europe is not counted slow because Sydney is far away. A monitor with no audience counts every voting probe. The target is **Fast within (ms)** in the monitor's Speed settings, from 50 to 60,000 ms; left empty it is 1,000 ms for HTTP and TLS checks and 200 ms for the other types. Speed is only a figure: it sends no alerts and is separate from the **Slow above** threshold, which does. Changing the target or the audience regions recounts the last 14 days at once; older hours keep the target they were counted with. Heartbeats have no Speed. The monitors list shows the last 24 hours, for example «96% fast». The monitor page shows the same figure under *Avg response*, and a Speed section with 24 hours, 7 days and 30 days and the p75 of each, naming the regions it counts, for example «from your visitors' regions: Europe». Under it, **By city · 24 hours** gives each voting probe's median check as a bar, split into network, DNS and TLS, server, and redirects and download, with the share of its checks within the target; cities outside the audience regions are greyed out, listed last and not counted, with a link to change the regions. **Server time ≈** is the part your server takes to answer, about the same from every city; the rest is distance and the network, which a CDN or a server nearer your visitors shortens. In the [API](https://pingwise.com/docs/api/), a monitor has `speed_target_ms` (writable, 50–60000 or `null` for the default) and `speed_target`, the one in use, and the monitor detail has `speed` with `24h`, `7d` and `30d`, each `{within_target, p75_ms, target_ms, checks}`, or `null` without checks. --- # Import from another service > Bring monitors from UptimeRobot, updown.io, Uptime Kuma or a CSV, then compare the two services for 14 days. Page: https://pingwise.com/docs/import/ Site: https://pingwise.com Language: en Updated: 2026-11-01 **Monitors → Import.** Four sources: - **UptimeRobot**: paste a read-only API key. We read the monitor list and do not store the key. - **updown.io**: the same, with a read-only key. - **Uptime Kuma**: upload the backup JSON that Kuma exports. - **CSV**: upload a file. Comma or semicolon separated, header row optional. Files are limited to 2 MB and 5,000 rows. ## CSV columns `url, name, interval, group, type, host, port, keyword, paused` Without a header the order is url, name, interval, group. Interval takes values like `30s`, `5m` or `1h` and defaults to 5 minutes. Type is `http` unless you say otherwise; for `tcp`, `smtp`, `dns` and `tls` give host and port. ## What happens to the drafts The import shows every monitor as a draft before anything is created. Intervals snap to the nearest PingWise interval, 10 seconds included, targets that are already monitored are flagged as duplicates, and credential headers are never imported. The cost in credits is shown before you confirm. Drafts for hosts on domains you have not verified keep their interval; only a port outside the common ones or a custom HTTP request needs the domain verified, and the preview says which. ## The 14-day comparison After an import from UptimeRobot or updown.io you can opt in to a comparison: for fourteen days their alerts are set against what our probes saw at the same moment and each is labelled *confirmed*, *not confirmed* or *unjudged*. It is the simplest way to see how many of the alerts you used to get were real. The [switch page](https://pingwise.com/switch/) explains the method. ## Quick add The one-line box at the top of the Monitors page takes one or more bare addresses, with or without a scheme. Ports 80, 443, 8080 and 8443 become HTTP monitors, 25, 465 and 587 SMTP, and any other port a TCP check. Up to 20 drafts at a time, each confirmed before it is created. On accounts where the AI features are turned on, the box also reads free text ("the shop and the API every minute, the blog every 5"); the AI never sets headers, bodies, credentials or write methods. --- # Alert channels > Email, Telegram, Slack, Discord, Teams, Google Chat, PagerDuty, Pushover, ntfy and webhooks: what each needs and how it is confirmed. Page: https://pingwise.com/docs/alert-channels/ Site: https://pingwise.com Language: en Updated: 2026-11-04 **Alerts → Channels → Add channel.** A channel is one destination. It receives alerts for every monitor in the account unless you select monitors or groups on its page, and you can have as many channels as you like. Every account starts with one: when the owner's email address is verified, an email channel to that address is created for every monitor, listed on Alerts as «Added when you signed up; change or remove it here». Only the owner's own verified address gets this, never a member's, and an account that already has a channel gets nothing. An account with running monitors and no working channel shows a banner on every panel page («N monitors, no alert channel: nothing will reach you when a site goes down»), with a one-click button for the owner that creates the same email channel; nothing is created without that click. A hosting provider sees a «no alert channel» chip next to each customer account that nobody would hear about. ## The ten types | Type | What you give us | Confirmed by | |---|---|---| | Email | an address | a link in a confirmation email; press the button on that page | | Telegram | nothing: open the *Connect Telegram* link, or add the bot to a group and send `/start ` there | the bot replying "Connected to …" | | Slack | an incoming-webhook URL from Slack | a "PingWise is connected" message | | Microsoft Teams | a Workflows webhook URL (the old Office 365 connector and logic.azure.com links are refused) | the same | | Discord | a channel webhook URL | the same | | Google Chat | a space webhook URL | the same | | PagerDuty | a 32-character Events API v2 integration key; tick *EU service region* if your account is there | a change event, which pages nobody | | Pushover | your user or group key; optionally your own app token, one device, and *Emergency priority* | a test message | | ntfy | the topic URL, and an access token if the topic needs one | a test message | | Webhook | an https URL without a username or password; private and reserved addresses are refused | created at once; see [Webhooks](https://pingwise.com/docs/webhooks/) | Chat services must be given their official webhook URLs, over https; a URL the service refuses means the channel is not created. Keys and URLs are stored encrypted and never shown again: to change one, remove the channel and add it again. **Pushover emergency priority** repeats the message every 60 seconds for up to an hour until someone acknowledges it on their phone, and the repeat is cancelled when the monitor recovers. ## Per-channel settings - **Delay**: alert immediately, or only after the monitor has been down for 2, 5, 10, 15, 30 or 60 minutes. If it recovers inside the delay, neither the outage nor the recovery is sent. - **Reminders while down**: never, or every 5, 10, 15, 30 or 60 minutes, or every 4 hours, at most 15 per outage. PagerDuty never gets reminders; it has its own escalation. - **Only if nobody has acknowledged it**: with a delay set, the channel is skipped when someone acknowledged the outage before the delay ran out. See [Acknowledging and escalation](https://pingwise.com/docs/alert-rules/#acknowledging-and-escalation). - **Also alert when a WAF blocks our probes**: on by default. - **Monitors and groups**: leave empty for every monitor, or pick some. A group covers monitors added to it later. - Resellers can tick *Also alert for my customers' monitors*. ## On the channel page *Send test* once the channel is ready (on PagerDuty it opens a real incident and resolves it at once), *Enable* / *Disable*, *Remove*, and a log of the last 20 alerts sent to it. An email address that bounces or is marked as spam stops receiving until you press *Try again*. ## What is not there No SMS, no voice calls, no acknowledgement inside PingWise, no quiet hours and no escalation chains: for those, hand the alert to PagerDuty or Pushover, which do them well. --- # When alerts are sent > Which changes send an alert, what the message contains, and how grouped sites, delays and reminders work. Page: https://pingwise.com/docs/alert-rules/ Site: https://pingwise.com Language: en Updated: 2026-11-04 ## Events A channel is told about a **change of state**, never about a single failed check: - **Down**, and **Up** again after a down. - **Blocked** by a firewall or a Cloudflare challenge, and **no longer blocked** (per channel, on by default). - **Partial**: unreachable from some continents only, and **reachable everywhere** again. Off unless the monitor's *Alert on partial outages* is on. - **Slow**, and **normal speed** again. Off unless the monitor's *Alert when it turns slow* is on. - **Heartbeat missed**: a heartbeat monitor whose job did not call in, or called `/fail`. - **Domain expiring**: 30, 14, 7 and 1 days before a domain of one of your monitors expires, and on the day. - **Credits running low**, sent to the account's channels. A monitor whose state was unknown or unconfirmed and becomes up sends nothing, so a new monitor does not announce itself. Pausing, resuming and maintenance windows send nothing. A certificate about to expire is shown as a warning in the panel and is not alerted; an expired certificate is an outage. ## The message The subject or title is `: `, for example `Down: shop.example.com` or `Still down: shop.example.com` for a reminder. The body carries the target, the reason and its detail, "confirmed from N locations on K continents at