Uptime Reports

The uptime report table is the central view for SLA tracking in PulsAPI. It shows real-time and historical performance data for every service you monitor.

Accessing the report

1. Navigate to the SLA section from the sidebar.
2. The report table loads with all your monitored services.
3. Use the time window selector at the top to switch between 7-day, 30-day, and 90-day views.

Reading the report table

Each row in the table represents a single service or component. The columns are:

Understanding uptime %

Uptime is calculated as:

Uptime % = (Total minutes operational / Total minutes in window) x 100

• Operational status counts as full uptime.
• Degraded performance counts as partial uptime (weighted at 50%).
• Partial outage and major outage count as downtime.

For example, with a 30-day window (43,200 minutes), a service that experienced 45 minutes of major outage would show:

(43,200 - 45) / 43,200 x 100 = 99.896%

Understanding downtime budget

The downtime budget tells you how much downtime you can still tolerate before the SLA is breached. It is calculated based on your configured SLA target and the selected time window.

For a 99.9% SLA target over 30 days:

Allowed downtime = 43,200 x (1 - 0.999) = 43.2 minutes

If 20 minutes of downtime have already occurred, the remaining budget is 23.2 minutes.

When the budget reaches zero, the SLA is marked as breached.

Latency percentiles explained

PulsAPI reports three latency percentiles for each service:

• P50 (median) — Half of all status checks completed faster than this value. This represents the typical response time your application experiences when polling the service.
• P95 — 95% of checks completed faster than this value. This is the standard SRE benchmark for "realistic worst-case" performance and is the most commonly referenced percentile in SLA discussions.
• P99 — 99% of checks completed faster than this value. This captures tail latency: the slow responses that affect 1 in 100 requests. High P99 relative to P95 indicates occasional severe latency spikes, which may not be reflected in uptime metrics but can still cause timeouts in your application.

Breach detection and alerts

PulsAPI automatically detects when a service's uptime drops below its configured SLA target.

When a breach occurs:

1. The service row in the report table is highlighted with a breach indicator.
2. If you have alerts configured (Slack, Discord, email, or webhook), a breach notification is sent immediately.
3. The breach event is recorded in the service's breach history, accessible by clicking the breach indicator.
4. The breach remains flagged until the time window rolls forward and uptime recovers above the target.

Breach event history

Click the breach indicator on any service row to view the full breach event log for that service. Each breach event records:

• The timestamp when the breach threshold was crossed
• The uptime percentage at the time of breach
• The SLA target that was breached
• The cumulative downtime minutes that triggered the breach

This history is useful for postmortems, vendor negotiations, and SLA credit claims.

Setting SLA targets

PulsAPI resolves SLA targets automatically (see SLA target resolution), but you can override them at any time:

1. In the SLA report table, click the SLA Target cell for a service.
2. Enter your custom target percentage (e.g., 99.95).
3. Press Enter or click Save.

PulsAPI immediately begins tracking breaches against your custom target. The SLA Source column will update to show Custom.

Filtering and sorting

• Filter by status — Show only services that are currently experiencing issues.
• Filter by breach — Show only services that have breached their SLA target.
• Sort by any column — Click a column header to sort ascending or descending.
• Search — Use the search bar to find a specific service by name.