SLA and uptime reporting: numbers grounded in incident history

SitePuls tracks monitor state changes over time. SLA-style views use that incident history—not synthetic marketing percentages—so teams can compare actual downtime to targets on supported plans.

What “incident-based” means

Uptime percentages derive from recorded down/up intervals for monitors, not from external analytics pixels.

Where to read SLA in the product

Open monitor detail and reporting areas in the app—labels follow the current UI (e.g., 7d/30d windows where available).

Targets and breaches

Configure targets that the product supports; breaches highlight when observed uptime falls below your goal.

Compared to raw uptime monitoring

Uptime monitoring answers “is it up now?” Reporting answers “how stable was it this month?”

Exports

Use built-in exports where offered—see reports sections for CSV or email schedules on your plan.

Relation to status pages

Public status shows current posture; SLA views help internal postmortems.

What SitePuls does not do

Legal SLA contracts or credit calculations—reporting supports operations, not billing automation by itself.

Next steps

Ensure monitors have clean incident data, then review SLA panels after meaningful observation windows.

What you can verify with SitePuls here

  • SLA-style percentages and downtime minutes in the signed-in report flow use `calculate_monitor_sla` (CheckHistory-backed windows such as 24h, 7d, and 30d); incident timelines complement that view for outage context.
  • Signed-in operators can download a CSV from `/site/<monitor id>/report/download` with `range=24h|7d|30d` (default 24h). Rows include monitor name and type, selected range, SLA target %, actual uptime %, downtime minutes, incidents count in that window, and average response time in milliseconds when check history exists.
  • The same aggregates can be emailed via `POST /site/<monitor id>/report/email` with a recipient address and optional subject—distinct from incident alert emails, which fire on state changes rather than on-demand summaries.
  • CSV download and emailed reports require an authenticated workspace user with access to the monitor; there is no public anonymous export of private dashboards.

Where incident alerts can go

  • Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
  • Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
  • HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
  • Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.

Illustrative sample — field names match the product; values are placeholders.

Example: SLA report CSV rows (download)

Monitor name,Example monitor
Monitor type,http
Range,7d
SLA target %,99.90
Actual uptime %,99.95
Downtime (minutes),12
Incidents count,1
Avg response time (ms),180

FAQ

Is SLA reporting on every plan?

Feature availability follows your subscription—check pricing and in-app capabilities.

Can I export for auditors?

Use report exports where enabled; align retention with your compliance needs.

Does it include API monitors?

Incidents for REST and HTTP monitors contribute to history when configured.

Timezone?

Follow account and UI settings in the product for displayed times.

Synthetic vs real user metrics?

SitePuls emphasizes synthetic checks; RUM is out of scope.

Custom SLA windows?

Use the windows the UI exposes—advanced custom calendars may be limited.

Multi-region SLA?

Regional monitors roll into their own incident timelines—aggregate reporting depends on how you group monitors.

Where do I start?

Open a mature monitor with weeks of data and navigate to SLA/uptime sections in the app.

Start free View pricing