Pro unlocked free during beta • 50 monitors • 60-sec checks • No credit card
First, drop your email on the landing page waitlist (pinginn.com). We manually approve beta users. Until your email is on the waitlist, app signups are blocked.
Once approved, go to the sign up page and create an account using the same email. If your email isn’t on the beta waitlist, you’ll see an error message and signup won’t be successful.
After signup you’re automatically logged in, a team is created for you, and you start on Pro tier during beta (with all the fancy stuff).
In Settings → Default Monitor Settings, pick your default interval, timeout, and retries.
Go to Monitors → Add Monitor, fill out the form (name, URL, method, interval, etc.), save it, and Pinginn will start checking it automatically.
Name: Label for the monitor shown on all app pages.
URL: The HTTP/HTTPS endpoint to check (e.g. https://api.example.com/health).
HTTP Method:
HEAD (default, fastest) – checks headers only.
GET – fetches the full response (used for keyword checks).
POST – sends a request body if needed (also supports keyword checks).
Expected keyword (GET/POST, optional): If set, a check only counts as “up” when this text appears in the response body; we read the body in memory to look for it and then discard it.
Request body (POST, optional): JSON payload you send with the request (must be valid JSON if provided).
Request headers (POST, optional): JSON object of headers (e.g. {"Authorization": "Bearer …"}); must be valid JSON and an object if provided.
Interval: How often we run checks; the backend will block anything below your tier’s minimum.
Timeout: How long we wait for a response before treating it as a timeout.
Retries: How many attempts we make within a single scheduled check before marking the monitor as down. Each retry waits 10 seconds before trying again. For example, with retries set to 3: attempt 1 fails → wait 10s → attempt 2 fails → wait 10s → attempt 3 fails → monitor marked down and alert sent. This helps avoid false alarms from brief network blips without delaying real alerts.
States: Enabled + not paused → monitor is actively checked on its interval. Paused → you explicitly pause a monitor; it keeps history but no new checks run until resumed. Disabled → used for tier enforcement (e.g. when a Free team has more than the allowed monitors, all are disabled until they delete back down).
When a check exhausts all its retries (with 10-second pauses between each) and still fails, we mark the monitor down, create an incident, and send alerts. You don't wait for multiple check intervals — retries are the buffer.
When the monitor recovers, the incident is marked resolved and a single “back up” alert is sent.
This means you get one alert when it breaks, one when it’s back, not a 3am storm of flapping emails.
Email alerts: In Settings → Email Notifications, enable email alerts, set an alert recipient, and configure SMTP (host, port, username, password, encryption). Alerts send via your SMTP server; we don’t keep the email content as a separate store.
Slack alerts (Pro): In Settings → Slack Notifications (unlocked on Pro), enable Slack alerts and paste an incoming webhook URL; Pinginn will post incident open/resolved messages into that channel.
Every check result is stored as up or down along with status code, response time, and an optional error message.
When a scheduled check exhausts all its retries and still fails, Pinginn opens an incident for that monitor and sets status = open.
As long as checks keep failing, we increment the same incident’s failureCount and update lastError/lastErrorAt instead of opening new incidents.
Once checks succeed again, the open incident is marked resolved and gets a resolvedAt timestamp.
That incident is then used in MTTR (mean time to recovery) and reports, but no longer shows as “active” on the dashboard.
Dashboard: The “Active Incidents” card shows how many are currently open and lists open incidents in the sidebar.
Incidents page: Full incident history with filters (all/open/resolved), time range selector, MTTR, and (on Pro) an incident frequency chart and CSV export.
Per‑monitor pages: Each monitor’s detail view shows its own checks and incidents over your retention window.
Free tier keeps around 30 days of checks/incidents; Pro keeps around 90 days, and extended ranges (60d/90d) on Incidents/Reports are Pro‑only.
A daily purge job runs in the background to clean out old check/incident rows based on your plan’s retention, so you don’t have to manage it manually.
The REST API is Pro‑only and uses per‑team API tokens.
During private beta, new teams start on Pro, but you still need to explicitly generate a token in Settings.
Go to Settings → API Access, click Generate Token, and copy the token shown (it looks like pi_live_… and is only shown once).
Use it in the Authorization header on every request: Authorization: Bearer pi_live_xxx
You can regenerate or revoke the token in the same section; under the hood, we store only a hashed version and enforce a 20 requests/minute rate limit per IP.
GET /api/v1/monitors – list all monitors for your team (basic fields, no heavy stats).
GET /api/v1/monitors/:id – fetch a single monitor by ID.
POST /api/v1/monitors – create a monitor (same fields as the UI: name, url, method, interval, timeout, retries, optional body/headers/keyword).
PATCH /api/v1/monitors/:id – update a monitor (e.g. change interval, pause/resume, update URL).
DELETE /api/v1/monitors/:id – delete a monitor and its associated checks/incidents.
The API enforces the same monitor limits and minimum intervals as the app.
If you send an interval below your tier’s minimum or try to create more monitors than your limit (including packs), the API returns a 403 with a helpful error message instead of silently accepting it.