Frequently asked questions
Everything about how PulseWatch checks your endpoints, what it records, and where the honest limits of hosted monitoring are.
Monitoring basics
- How does PulseWatch monitor my site?
- PulseWatch makes a real HTTP or HTTPS request from its own servers to the URL you configure, then records the HTTP status code, the round-trip response time and any transport error. Nothing is simulated.
- How often are checks run?
- A database scheduler runs every minute and executes only the monitors that are due. Each monitor has its own interval — for example 60 seconds or 300 seconds — which decides how often it is due.
- What counts as downtime?
- A check fails when the endpoint does not answer within your timeout, answers with a status code that does not match your expected status, or fails a configured keyword match. Failures are recorded individually; an outage is only declared once your failure threshold is reached.
- What does the response time mean?
- It is the round-trip time measured server-side for that single request, in milliseconds. It includes connection and TLS setup plus the time to first response, and it will vary with network conditions between our runtime and your server.
- How do incidents and recovery work?
- When a monitor reaches its failure threshold an incident opens with a start time. When the endpoint passes again the incident closes and its duration is stored, so your incident history reflects real observed outages.
- Which monitor types are supported?
- HTTP and HTTPS checks, including keyword/content matching, are fully supported. DNS checks and TCP port checks are implemented and run where the hosting runtime permits that kind of connection; where it does not, PulseWatch records a runtime limitation instead of inventing a result.
- Does PulseWatch monitor SSL certificates?
- Yes, where the runtime supports TLS certificate inspection. In that case the certificate expiry date, days remaining and issuer are recorded. Where inspection is not available, the certificate information is clearly labelled as unavailable rather than estimated.
Alerts and status pages
- Will I get an email when my site goes down?
- Where email alerting is configured for your account, PulseWatch sends a DOWN email when an incident opens and a RECOVERED email when it closes. Every send is logged so you can confirm what was sent and when.
- Can I share a public status page?
- Yes. You can publish a status page containing only the monitors you explicitly mark as public. It shows status, uptime, response time and incident history. Private monitors and full monitor URLs are never exposed on it.
Privacy, security and data
- Who can see my monitors and results?
- Only your account. Monitors, checks and incidents are protected by database row-level security, so another signed-in user cannot read your rows.
- Does PulseWatch store my site's response body?
- No. The public one-off checker stores nothing at all. Monitor checks store metadata only — timestamp, up/down, status code, response time and any error. Keyword monitors read a size-capped portion of the response purely to test for a match; arbitrary response bodies are not retained.
- How does PulseWatch prevent its checker being abused?
- Every target URL is validated before a request is made. Non-HTTP protocols, private and loopback ranges, link-local addresses, cloud metadata endpoints and internal-only hostnames are rejected, DNS answers are re-checked to defend against rebinding, every redirect hop is re-validated, and requests carry timeouts and response-size caps. The public checker is also rate limited per network.
- Can I sign in with Google?
- Yes. Google sign-in is available alongside email and password sign-in on the sign-in page.
- How do I delete my account and data?
- You can delete individual monitors at any time, which removes their checks and incidents. Full account deletion is handled on request by the site owner — see the Privacy Policy for how account data is handled.
Plans and limitations
- Is PulseWatch free?
- The current service is free to use while it is in active development, with sensible per-account limits on monitors and check frequency. Paid plans are not available yet and no pricing has been published.
- What are the limitations of hosted monitoring?
- Checks run from a single hosted runtime, so PulseWatch sees your endpoint the way that runtime does. It cannot detect problems that only affect other regions or networks, it cannot reach services on private networks, and some low-level connection types depend on what the runtime permits. PulseWatch reports those limits openly rather than guessing.
- How do I get support?
- PulseWatch does not yet publish a dedicated support inbox. If you reached this service through 1Desk, use your existing 1Desk contact route until a support address is published here.
Still deciding?
Run a free one-off check, or read the full walkthrough of a PulseWatch check.