Communicate

Reporting: availability, SLA, performance and scheduled delivery

The six report types and their CSV/PDF exports, SLA targets and error budgets, custom reports with widgets, and scheduled reports that arrive as a written report rather than a bare link.

Reporting is on Pro and above. Every report is available in the app and as JSON, CSV or PDF from the same endpoint (?format=json|csv|pdf), and on a schedule to any notification destination.

Reporting endpoints — /api/v1/reports, /api/v1/sla-targets, /api/v1/custom-reports, /api/v1/scheduled-reports and /api/v1/dashboards — are session-authenticated and not part of the API-key surface: an API key gets 403 FORBIDDEN. Reports fan out over every monitor in the organization, so they carry their own rate limit, separate from the rest of the app.

Report types

ReportRouteContents
AvailabilityGET /api/v1/reports/availabilityUptime per monitor over the period, with downtime totals and the incidents that caused them.
PerformanceGET /api/v1/reports/performanceResponse-time distribution per monitor (percentiles, trend), and the anomalies recorded.
SLAGET /api/v1/reports/slaAvailability against each SLA target, met/missed, and the remaining error budget for the period.
IncidentsGET /api/v1/reports/incidents (+ /export)Every incident in the period: source, duration, acknowledge and resolve times.
IntelligenceGET /api/v1/reports/intelligenceChange events, anomalies and correlations, by monitor and category.
Monitor healthGET /api/v1/reports/monitor-healthWhich monitors are noisy, flapping, misconfigured or never succeeded.

SLA targets

An SLA target (/api/v1/sla-targets) pairs a set of monitors with an availability percentage and a period of daily, weekly, monthly or quarterly. The SLA report computes achieved availability per target and the error budget left in the current period, and the SLA calculator shows what a target means in minutes.

Custom reports

A custom report (/api/v1/custom-reports) is a named page of widgets — availability, performance, sla, incidents, intelligence, monitor_health — over a chosen period, with visibility of private, organization or shared (to shared_with_user_ids). Use one for the monthly ops review and another for a customer's QBR.

Scheduled reports

FieldValues
nameRequired. It is the headline of what gets delivered, so name it for the reader: "Acme — monthly SLA".
report_typeavailability · performance · sla · incidents · intelligence · monitor_health · custom (with custom_report_id)
frequencydaily · weekly (requires day_of_week, 0 = Sunday … 6 = Saturday) · monthly / quarterly (require day_of_month, 1–28)
time_of_day, timezoneHH:MM 24-hour (default 09:00) in any IANA timezone (default UTC), e.g. 08:00 / Europe/Berlin. The IANA database ships inside the service, so every zone resolves in production exactly as it does on a developer machine.
destination_ids1–20 notification destinations that receive the scheduled_report event — an email destination for the client contact, a Slack channel for the team.
enabledPause without deleting. next_run_at, last_run_at, last_status and last_error are read-only.

day_of_month stops at 28 on purpose: a schedule set for the 31st would skip February. Creating, editing and deleting a schedule is owner/admin; every member can see what is scheduled and how the last run went.

What actually gets delivered

A scheduled report is written out, not just announced. When it fires, PulseTrace runs the same calculation the report page runs, over the window the frequency names, and renders it three ways — so each destination receives the form that suits it:

DestinationWhat it receives
EmailThe report itself: a written summary, the period it covers, and the tables that matter for that report type — uptime and downtime per monitor, percentile movement against the previous period, SLA attainment and error budget, the incidents with their causes, the changes recorded, or the unhealthy monitors. Long lists stop at ten rows with an "and N more" link.
Slack · Teams · Discord · TelegramA short summary of the same numbers, written to be read in a channel without opening anything.
WebhookThe rendered report object alongside the usual scheduled_report event fields, for anything you want to do with it downstream.

Every delivery links back to the report page with the matching period already applied (…/dashboard/reporting/availability?period=daily), plus a link to the schedule list in the footer. If the calculation fails for any reason the delivery still goes out with the link rather than going silent, and the run is not marked failed for that alone.

Those links are built from the app's configured public address. A deployment left on a localhost address produces links nobody outside the server can open, so the service logs a warning about it at startup.
scheduled-report.jsonjson
{
  "name": "Acme — monthly SLA",
  "report_type": "sla",
  "frequency": "monthly",
  "day_of_month": 1,
  "time_of_day": "07:00",
  "timezone": "Europe/Berlin",
  "destination_ids": ["…"],
  "enabled": true
}

The cron builder is handy for reasoning about a schedule, but scheduled reports use the fields above rather than a cron expression.

Try it on your own endpoints.

Ten monitors, one region and a status page are free — no card.

Start free