deplo.ai/docs

Monitoring & Analytics

Every deployed project gets built-in health monitoring — uptime probes, latency history, and live server metrics from your own Render service — plus optional, cookieless product analytics via a one-line snippet. No agents to install, nothing to configure.

Find it in the dashboard: open a project's deployment page and go to Project monitoring & analytics. The same data is available from the Monitoring API.

Uptime probes#

A background worker probes the live URLs of every project every 5 minutes. The URLs come from the latest COMPLETED deployment per repository — frontend and backend are probed separately. Samples are retained for 7 days.

RuleValue
Probe intervalEvery 5 minutes, per target (frontend + backend)
Up (ok)Any HTTP status < 500 — redirects are followed
DownHTTP 5xx, connection errors, or no response within the 15-second timeout
Retention7 days of samples
Note
Free-tier backends sleep when idle, so the first request after a quiet period is slow. A slow response still counts as up — only errors and timeouts count as down. Expect the latency chart to show cold-start spikes on free plans.

Uptime percentage and latency#

For each target the monitoring view shows:

  • Current status — the most recent probe's result, HTTP status, and latency.
  • 24-hour uptime % — the share of probes in the last 24 hours that were up, to one decimal place.
  • Latency series — every sample from the last 24 hours, charted so you can spot degradation and cold starts.

Live server metrics (Render)#

When the project has a backend, deplo.ai also fetches live CPU and memory series for the last hour directly from the Render service — using your own Render API key, since the service runs in your workspace. This is best-effort: if the key was disconnected or Render's metrics API is unavailable, the health and uptime data still load and the server panel is simply omitted.

Latest-attempt banner#

Monitoring always distinguishes what is live from what happened last. Uptime probes track the latest successful deployment's URLs — but if a newer attempt failed (or is still in progress), a banner shows its status and error above the health data. So when a deploy fails, you see the failure immediately, while the charts confirm your previous version is still serving traffic. See Troubleshooting.

Product analytics#

Analytics is opt-in per project: copy the snippet from the dashboard's analytics panel and add it to your deployed site. It is one script tag — the data-deplo-key is your project's ID:

index.html
<script defer src="https://www.deplo.in/api/v1/public/insights.js" data-deplo-key="YOUR_PROJECT_ID"></script>

The script is ~15 lines, cached for an hour, and sends a beacon on page load and on every SPA navigation (it hooks pushState, replaceState, and popstate), using navigator.sendBeacon with an image-request fallback. It never blocks your page.

What is collected#

FieldDetail
PathThe page path, e.g. /pricing
ReferrerThe document referrer; empty referrers are reported as (direct)
Visitor hashsha256(ip | user-agent | day | projectId), truncated — a cookieless daily identifier
  • Requests from bots and crawlers (user-agent match) are dropped.
  • Visitors sending the DNT: 1 (Do Not Track) header are not recorded.
Privacy
No cookies, no localStorage, no fingerprinting scripts. The raw IP address is never stored — it only passes through the hash, and because the current day is part of the input, the identifier rotates every 24 hours and cannot track a visitor across days or across projects.

Reading the numbers#

The analytics view covers a window of 1 to 30 days (default 7) and shows:

  • Views — total pageviews in the window, plus a per-day series.
  • Visitors — unique daily visitor hashes.
  • Top pages — the ten most-viewed paths.
  • Top referrers — the ten most common traffic sources, with direct traffic grouped as (direct).

Next steps#