SLA reports and targets

An SLA target is the uptime percentage you promise, or aim for, on a monitor, such as 99.5%. Pingara compares each monitor's real uptime with its target and labels it met, at risk or breached. SLA Reports in the sidebar shows those labels for every monitor that has a target.

Try this: edit a monitor, enter 99.9 in SLA Target (%) under Advanced Settings, save, then open SLA Reports and pick Last 30 days.

Set an SLA target

1. Open a monitor and press Edit Monitor, or start a new monitor.
2. In Advanced Settings, enter a percentage in SLA Target (%), for example 99.9.
3. Save the monitor.

The field takes a number from 0 to 100 with up to two decimals. Leave it empty and Pingara does not track an SLA for that monitor. Owners, admins and editors can set it, because it is part of the monitor. You can also set it with the slaTarget field in the Developer API.

What met, at risk and breached mean

Pingara compares the monitor's actual uptime for the period with its target:

The 0.1 is percentage points, not a percentage of the target. It is a fixed margin, so it does not change with the target you set. With a target of 99.9:

At risk is not an early warning. It means uptime is already below your target, by a small amount, so the target has been missed for that period. Breached means it was missed by more. The margin is the actual uptime minus the target, in percentage points, rounded to two decimals.

SLA status is a report that you read after the fact, using completed days. Pingara does not send a notification when a monitor becomes at risk or breached. To be told about an outage as it happens, set up alert channels instead.

How uptime is calculated

Actual uptime is the share of checks that succeeded: successful checks divided by all checks in the period, rounded to two decimals. It counts checks, not minutes, so a monitor that checks every 5 minutes measures downtime in steps of 5 minutes.

Two things follow from counting checks, and both matter if you use the report as evidence:

• Time with no checks is not counted as downtime. A period with no checks reads as 100%. A monitor that was paused for the whole range, or that no probe checked, shows 100% uptime and SLA Met. Paused time inside a longer range drops out of the figure rather than counting against you. Before you export a report as proof of uptime, check that the monitor was active for the period.
• Every failed check counts, even without an incident. Checks from every region you monitor from are pooled together. One region's failed check lowers uptime even when the other regions passed and Pingara never opened an incident, because an incident needs enough regions to agree. So a day can fall below your target with no incident to match it. The report is not wrong, it counts every failed check.

The report is built from Pingara's daily summaries, one per completed UTC day. Pingara writes yesterday's summary shortly after 00:15 UTC, so today's checks do not appear until tomorrow. The first day of a range is included only if it falls fully inside it, so Last 30 days usually covers 29 complete days.

The dashboard's monitors table also shows an SLA badge for monitors with a target. It scores the uptime figure that table shows, which covers the last 24 hours, so it can say something different from a 30-day report. Neither is wrong: they measure different windows.

Read the SLA Reports page

Choose a range from the menu: Last 7 days, Last 30 days, Last 90 days or Last 365 days. The page shows four summary cards and a table:

• Org-Wide Uptime. Uptime across every monitor that has a target, pooling all their checks.
• SLA Met, At Risk and Breached. How many monitors fall into each status.
• Monitor SLA Compliance. One row per monitor with its target, actual uptime, margin and status.

Monitors without a target are not counted. If none of your monitors has one, the page tells you to set one.

Breach history

Click a monitor's row to open its breach history. It lists each day in the range when that day's uptime was below the target, with the day's uptime, the shortfall and how many checks failed. A day with no checks counts as 100%, so it never appears here. A breach day can show failed checks with no matching incident, for the reason above. The history looks at single days, so a monitor can be met over 30 days and still show a few breach days.

Calendar months

The page has no calendar-month range. If you ask Ara about a past month, it answers from the last 3 complete UTC calendar months, measured against the monitor's current target because Pingara keeps no record of earlier targets. Those monthly figures are not on this page, but you can check the days it counts as below target under Last 365 days.

Export a report

On the Pro plan, the Export button on SLA Reports downloads a CSV of every monitor in the range, or lets you print the page or save it as a PDF. Free plans see the page but not the export. See Plans and Pricing.

The Developer API also returns an sla block with each monitor's target, status and margin on the Pro plan. See Developer API.

Choosing a target

• Start from what you can sustain. A target you cannot meet is breached every month and stops meaning anything.
• Know what a target allows. At a target of 99.9 percent, a 30-day month allows about 43 minutes of downtime. At 99.99 percent it allows about 4 minutes, which one slow deploy can use up.
• Match your promise, or set the target just above it. If your contract promises 99.5 percent and you set the target to 99.5 here, at risk already means Pingara's uptime figure is under the contract figure. To get a margin before that point, set an internal target 0.1 above the contract, here 99.6. Then at risk means Pingara's figure is within 0.1 points of the contract figure, and breached means Pingara's figure is below it. Right at the contract figure, rounding can tip a monitor either way, so do not read the exact boundary as meaningful. This only works for a contract of 99.9 percent or lower, because a target cannot be higher than 100.
• Pingara's figure is not a ruling on your contract. Pingara counts checks, not minutes, over completed UTC days. Time with no checks does not count as downtime, and checks made during a maintenance window count like any other check. Your contract may measure minutes, exclude scheduled maintenance or use calendar months, so work out whether it was met by its own rules. Use the report as your own early signal.
• Use alerts for live problems. SLA status changes only as days complete and sends no notification, so rely on your alert policies to hear about an outage while it is happening.

Next steps

• Apdex Scoring - Measure how fast, not just whether it is up
• Response time, percentiles and jitter - Read latency beyond the average
• Monitor Intervals and Regions - How often and from where Pingara checks