Uptime Reports
Turn your monitoring history into a clean, shareable SLA report — in about ten seconds.
What is an uptime report?
An uptime report is a point-in-time summary of how one or more of your monitors performed over a period you choose. You pick the monitors and the date range, and Enori rolls up the uptime percentage, response times, total downtime, and the incidents that happened — into a single page you can view, download, or share.
Example: "For January, my API was up 99.94% of the time, averaged 180ms, and had two short incidents totalling 26 minutes of downtime." That sentence, backed by data your customer can verify, is what a report gives you.
Reports are what you send to a client at the end of the month to prove you met your SLA, or what you keep on file as an internal record of reliability. You generate one on demand whenever you need it — and on Pro and Business you can also set up a schedule that generates and emails one automatically. Either way, Enori keeps every report you generate: they are never deleted on a retention timer, so a report you filed two years ago is still there.
When to use it
- Monthly SLA compliance. You promised a customer "99.5% uptime per month" and need to show you delivered. Generate a report for the calendar month and share the link (or send the PDF).
- Client reporting. Agencies and MSPs managing sites or infrastructure for clients — one report per client, covering the monitors you run for them.
- Post-incident records. After a rough week, a report gives you and your team a factual account of what went down, for how long, and when it recovered.
- Quarterly / annual reviews. A 90-day or 12-month report is a tidy reliability summary for a board pack or a contract renewal. Every plan can reach back at least a full year — see the period rules.
When you don't need a report: if you want continuous tracking of a reliability target with alerts when you're burning through your error budget, that's an SLO, not a report. Reports are a snapshot you pull when you need it; SLOs run in the background all the time. Many teams use both — an SLO for day-to-day insight, a monthly report for the customer.
How it works
When you generate a report, Enori computes it once, over the exact period you selected, and stores that result. Reopening the report later shows the same numbers — it is a frozen snapshot of the moment you created it, not a live view. If you want fresh numbers, generate a new report.
A few things make the numbers trustworthy for SLA purposes:
- Settled results only. A check that briefly looked down but was immediately re-verified and cleared does not count against you. Only confirmed results are included — the same math the monitor detail page uses, so a report never contradicts what you see elsewhere in the app.
- Maintenance is excluded. Any downtime that fell inside a maintenance window you had declared on the monitor is left out of the uptime and downtime figures. Planned work shouldn't count against your SLA.
- Downtime is grouped into periods. A run of consecutive failed checks is treated as one downtime period; when checks start passing again, that period closes and any later failure starts a new one. A single isolated failure counts as roughly one check-interval of downtime.
Because of this, the uptime %, the downtime minutes, and the incident list in a report all describe the same, consistent set of confirmed problems.
What a report contains
| Section | What's in it |
|---|---|
| Overall summary | Overall uptime %, average / P95 / P99 response time, total checks, total downtime, number of monitors, number of incidents, and the period length. |
| Downtime periods | Every confirmed downtime period across the selected monitors — which monitor, when it started, when it ended, and how long it lasted. Every period in a report is closed (a report is a snapshot of a finished period, so an outage still running when you generated it is recorded as ending at the end of the report period). A monitor that flapped rather than going down once can produce a very long list; a monitor with more than 100 separate periods lists only its 100 longest, and a data note says so. Downtime minutes and uptime % are always computed over all periods, so the totals are unaffected. (The table is shown only when there was downtime.) |
| Monitor breakdown | A per-monitor row: uptime %, avg / P95 / P99 response, total checks, and downtime. (Shown when the report covers two or more monitors — with a single monitor it would just repeat the overall summary, so it's hidden. This is true of the shared public page too.) |
| Incident timeline | Incidents that occurred during the period — time, title, monitor, duration, and severity (Critical / Major / Minor). (Shown only when there were incidents.) |
What "P95 / P99 response" means: the response time that 95% (or 99%) of your checks came in under. A low average with a high P99 tells you most requests are fast but a few are slow — useful for spotting tail latency. These are the average of each day's figure, not an exact pass over every individual check — which is what lets a report cover a year without keeping a year of per-check data. It is the same number the monitor detail page shows for its 7d / 30d / 90d ranges, so a report and the app agree. Every report says so in its own Data notes.
Data notes
Most reports carry a short Data notes block, just under the headline numbers. It is generated with the report and it states, in plain language, what the figures in that particular report do and do not cover. It appears on the report page, on the public shared page, in the PDF, and as a trailing block in the CSV — the same words on every copy, including the one you hand to a client.
You will see notes like these, and only when they apply:
- The percentile note. P95 / P99 and the average response time are the average of each day's aggregate, not an exact percentile over every check. This one appears on nearly every report.
- The retention note. The period reaches further back than your plan keeps individual check results. It names the cutoff date, says how many days of the period actually have data on record, and states that the downtime table therefore covers only the retained window and under-reports downtime before it.
- The coverage note. One or more selected monitors have no data for part of the period — most often because the monitor was paused for those days, but also if the period predates the monitor. Figures are computed over the days with data, not over the calendar period.
- The truncation note. A monitor had more than 100 separate downtime periods (a monitor that flapped). Only its 100 longest are listed; the downtime minutes and uptime % still count every one of them.
A report with nothing to declare shows no Data notes block at all.
When a report has no data
If a period had no settled checks at all — a monitor that was paused the whole time, or a window from before you created it — Enori does not print a confident 100.00%. The uptime figure reads "no data" on the report page and in the PDF, and the CSV leaves that cell empty rather than writing a number, so a spreadsheet cannot average a placeholder into a client's quarterly figure. If you see "no data" where you expected a percentage, check whether the monitors were paused over that period.
Generating a report
Open Reports in the sidebar (under Collaborate), or jump straight in from a monitor's Uptime History panel with SLA report (which pre-selects that monitor). Then click Generate Report and fill in the modal:
1. Report name
Required. It's pre-filled with something sensible like "January 2026 Uptime Report" — rename it to whatever your client will recognise ("Acme Corp — January SLA").
2. Start date and end date
Two date pickers, pre-filled to the previous calendar month. Rules:
- The end date must be the same day as, or after, the start date — a one-day report is allowed.
- The end date must be yesterday or earlier. A report covers whole UTC days, so picking today would ask for a day that has not finished; the request is refused with "PeriodEnd cannot be in the future". Generate today's figures from the monitor's own Uptime History panel instead.
- The period must fit within your plan's maximum: 365 days on Base, 730 (2 years) on Pro, 1095 (3 years) on Business. The modal shows "N days selected (max X)" and blocks generation if you go over. Both dates are read as UTC calendar days, and the period includes both of them.
Two different windows — this is the part worth reading. Your plan has two history settings and they are deliberately not the same number: - Uptime history (365 / 730 / 1095 days) — how far back a report can reach. Enori keeps one uptime record per monitor per day, for ever, so uptime %, check counts and daily response averages survive indefinitely. This is the number that caps your report period. - Data retention (30 days on Base, 60 on Pro, 90 on Business) — how long the individual check results are kept. The downtime-periods table is rebuilt from those individual checks, so it only covers the retained window. So a Business account can generate a 12-month report: the uptime %, check counts and response averages cover the whole year, while the downtime table covers the last 90 days. The report says exactly that in its Data notes — it never prints a figure without telling you what is behind it.
3. Monitors
A checklist of your monitors. Tick the ones this report should cover, or use Select all. At least one is required. A single report can cover up to 200 monitors on any plan — that is a limit on how much one report can compute in one go, not a plan lever. If you have more than 200, Select all takes the first 200 and tells you so; split the rest into a second report.
4. Generate
Click Generate Report. The report is computed and appears as a card in the grid. Its status moves from generating to ready (a few seconds for most accounts). The modal also shows a "X of N reports used this month" counter so you can see your remaining monthly quota.
Screenshot: the Generate Report modal with a name, date range, and two monitors selected.
Reading the results
Click any report card to open the full report. At the top you get the headline stat cards (overall uptime, avg / P95 / P99, total checks, monitors, incidents, total downtime, period length), followed by the downtime-periods table, the per-monitor breakdown, and the incident timeline.
Uptime figures are colour-coded so you can read health at a glance:
- 🟢 Green — 99.9% or higher.
- 🟡 Amber — 99% to 99.9%.
- 🔴 Red — below 99%.
Sharing a report
(Pro and Business plans.)
On a report, click Share. Enori creates a public link — app.enori.io/reports/ — and copies it to your clipboard. Anyone with the link can view the report in a clean, branded page and download it as a PDF, with no Enori account required.
The public page shows only the report's presentational data — uptime, response times, downtime, incidents. It deliberately does not expose any internal identifiers.
To stop sharing, click Unshare. The link stops working immediately — the public page shows "Report Not Found". If you share the report again later, it reuses the same URL, so a link you've already sent will start working again.
The link has no expiry and no password. The token is permanent: it cannot be time-boxed, password-protected, or rotated, and unsharing keeps it rather than replacing it. Anyone who has ever had the link gets the report back the moment you re-share. If a link needs to stop working for good, Unshare it and leave it unshared, or delete the report.
The shared page shows the same content as the report page — the headline numbers, the Data notes, the downtime-periods table, the per-monitor breakdown (when the report covers two or more monitors) and the incident timeline — and offers Print and Download PDF.
Screenshot: the public report viewer at
app.enori.io/reports/, showing the uptime hero and monitor breakdown.
Exporting: PDF and CSV
You have two export formats, and they're available on different plans:
| Format | Plans | What you get |
|---|---|---|
| CSV | All plans | A spreadsheet with one row per monitor (Monitor, URL, Uptime %, Avg, P95, P99, Total Checks, Failed Checks, Downtime) plus an Overall rollup row. Opens cleanly in Excel and Google Sheets. Best for your own records or further analysis. |
| Pro and Business | A print-ready document of the full report — the polished artefact to attach to an email or archive. |
To export, open the report and click CSV or PDF. You can also print or download a PDF straight from a shared report's public page.
In the CSV, any Data notes are appended after the numeric block, under a Data notes row, so the caveats travel with the file. The file is UTF-8 with a BOM and opens directly in Excel and Google Sheets.
In the PDF, you also get two charts — downtime by monitor and response time by monitor — showing the worst 15 monitors, with a line telling you how many were left out. Monitor names in Latin, Cyrillic, Greek, Japanese, Chinese, Arabic, Hebrew, Thai and Devanagari scripts all render. Korean (Hangul) is not covered: rather than printing a blank name, the download fails with "PDF generation temporarily unavailable". CSV export and the on-screen report are unaffected — rename the monitor if you need the PDF.
On Base, the PDF button isn't shown — CSV export is always available if you need the data in a file. Upgrade to Pro for PDF and public sharing.
Scheduled reports
(Pro and Business plans.)
A schedule generates a report on a recurring cadence and emails it, as a PDF attachment, to a list of recipients. It is the "send my client their uptime report on the 1st of every month" flow — you set it up once and stop remembering to do it.
You'll find Scheduled reports at the bottom of the Reports page. On Base the section is visible but locked, with an upgrade prompt.
Setting one up
Click New schedule and fill in:
| Field | What it does |
|---|---|
| Name | What the schedule (and the reports it generates) are called — e.g. "Weekly client uptime". |
| Monitors | Which monitors the report covers. At least one; they must be monitors you own. |
| Report period | Last 7 days or Last 30 days. See the note below — this is a rolling window. |
| Cadence | Weekly (pick a day of the week) or Monthly (pick a day of the month, 1–31). A day past the month's length runs on that month's last day, so "31" is 28 or 29 in February. |
| Send at | The hour, in UTC, from 00:00 UTC to 23:00 UTC. Defaults to 06:00 UTC. It is not converted to your local time zone — pick the UTC hour you want. |
| Recipients | Up to 10 email addresses. They do not need Enori accounts. |
| Active | Whether the schedule sends. Untick to keep the configuration without sending. |
Enori checks for due schedules every 15 minutes, so a send happens within roughly a quarter of an hour of the hour you chose.
"Monthly" is not a calendar month. The period is always the last 7 or last 30 days counted back from the moment the report runs — so a monthly schedule set to day 1 sends the 30 days ending on the 1st, not the calendar month that just finished. If you need a report that covers exactly "January", generate it by hand with the date pickers on the 1st.
Running, pausing, editing
- Run now pulls the schedule forward so it goes out on the next 15-minute tick — "Report will be sent shortly", not instantly. Your regular cadence is unaffected: once the run finishes, the next run is recomputed from the cadence as usual. It is offered on active schedules only; a paused schedule has to be activated first (over the API, running a paused schedule is refused with "This schedule is paused. Activate it before running it now.").
- Pause / Activate stops and restarts sending. A paused schedule keeps its name, monitors, recipients and cadence.
- Edit changes any field; the next run time is recomputed from the new cadence.
- Delete removes the schedule. Reports it already generated are kept.
Each card shows the cadence, the period, the monitor and recipient counts, and — while active — the next run time in your local time zone.
What a schedule counts against
| Base | Pro | Business | |
|---|---|---|---|
| Scheduled reports | — | 5 | 25 |
That is a cap on how many schedules exist, active or paused. At the cap, New schedule is disabled and the page tells you so; over the API the refusal is "Schedule limit reached (N). Upgrade your plan for more."
Scheduled runs do not use your monthly report quota. Schedules are capped by the number above instead, so three weekly schedules on Pro do not eat the 10 reports a month you generate by hand. The reports they produce still appear in your Reports grid, and you can open, share, export and delete them like any other.
Two things that will surprise you if nobody says them
- A downgrade silently switches your schedules off. If your plan stops including scheduled reports, the next time a schedule comes due Enori deactivates it instead of sending. There is no email about it — the reports simply stop arriving, and the schedule shows as Paused. If a client says their report stopped coming after a billing change, this is why.
- Deleting a monitor edits your schedules. The monitor is removed from every schedule that covered it, and a schedule left with no monitors is deactivated rather than being left to email an empty report every week. It is not deleted, so you can add monitors back and re-activate it.
Do reports send alerts?
No. Generating a report never triggers an alert, and a report you create by hand notifies nobody.
The one thing that does send email is a scheduled report — and it emails the recipients you listed on the schedule, on the cadence you set. It is a delivery, not an alert: it goes out whether reliability was good or bad, and it never pages anyone.
If you want to be told when reliability slips — before month-end, not after — set up an SLO on the monitor. SLOs track a target continuously and fire burn-rate alerts through your existing channels (email, Slack, Discord, Teams, webhook, push) when you're spending your error budget too fast. Reports and SLOs complement each other: the SLO watches in real time, the report documents the outcome.
FAQ
Why do the report numbers differ from what my dashboard shows now?
A report is a frozen snapshot taken when you generated it. Your live dashboard keeps updating; the report doesn't. If you want current numbers, generate a fresh report — the old one stays as your record of that period.
An outage I remember isn't in the report — why?
Two common reasons, both intentional: the downtime fell inside a maintenance window you'd declared (excluded by design so planned work doesn't count against your SLA), or the failed checks were re-verified and cleared as a false positive and so were never counted as confirmed downtime.
Can I report on a whole year?
Yes, on every plan. The maximum period is 365 days on Base, 730 on Pro, 1095 on Business. Uptime %, check counts and daily response averages cover the full span; the downtime-periods table only covers the window your plan retains individual checks for (30 / 60 / 90 days), and the report's Data notes say so on the report itself. For a longer span than your plan allows, generate several consecutive reports — which is also how most SLAs are structured anyway.
My report covers one monitor and there's no "Monitor Breakdown" table. Is that a bug?
No. With a single monitor, the per-monitor breakdown would be identical to the overall summary, so it's hidden to avoid showing the same numbers twice. The breakdown appears as soon as a report covers two or more monitors.
How long does Enori keep my reports?
Indefinitely. Reports are not deleted on a retention timer — they are yours until you delete them, or until you delete your account. So "keep one on file as an internal record" is a real filing cabinet, not a 90-day one. (Note this is separate from the individual check results behind a report, which are purged at your plan's retention. A report is a frozen snapshot, so purging the checks does not change the numbers already in it.)
Why does my report show "no data"?
Because nothing was measured in that window — usually the monitors were paused for the whole period, or the period is from before you created them. Enori prints the words rather than a confident 100.00%. See When a report has no data.
Can I generate reports from the API or an AI assistant?
Not today. Reports are a dashboard feature: the report endpoints don't accept API keys, and the Enori MCP server ships no report tool. Everything on this page is done from Reports in the sidebar. If you want reports automated, use a schedule — that is what it is for.
Can the person I share with edit or see my other data?
No. The public link is view-only and shows just that one report's numbers. It exposes no account details, no other monitors, and no internal identifiers. Revoke it any time with Unshare.
Does deleting a report free up a monthly slot?
Yes — for a report that succeeded. Your monthly limit counts the reports you generated by hand that currently exist for the UTC calendar month, so deleting one lets you generate another in its place.
Two things never count against it in the first place, so deleting them frees nothing: a report whose status is failed, and any report produced by a schedule.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| "Failed to download PDF. Pro or Business plan required." | Usually what it says — PDF export is Pro/Business. But this message is shown for any PDF failure from the report list, so on a Pro or Business account it means something else went wrong (see the "PDF generation temporarily unavailable" row). | On Base, use CSV (available on every plan) or upgrade to Pro. On Pro/Business, open the report and download the PDF from there — the message on the report page is not plan-specific. |
| Report card shows "failed". | Something went wrong during generation (e.g. a very wide window on a large account timing out). | Generate it again, ideally over a shorter period or fewer monitors. A failed report never used a monthly slot, so you have not lost one — and deleting it does not give one back. |
| "Period exceeds your plan limit of N days (M days selected)" in the Generate modal, and Generate Report stays greyed out. | The selected range is longer than your plan's uptime history. | Shorten the range to fit (365 / 730 / 1095 days by plan), or upgrade. Called directly over the API the same refusal reads "Report period exceeds your plan limit. Your {plan} plan allows up to {N} days of uptime history." |
| Shared link shows "Report Not Found". | Sharing was disabled, or the report was deleted. | Re-open the report and click Share again — it restores the same link. If the report was deleted, generate a new one. |
| Uptime looks higher than I expected. | Maintenance-window downtime and re-verified false positives are excluded from the figures. | This is correct SLA behaviour. If you want strict, everything-counts numbers, avoid declaring maintenance windows over the period. |
| "Generate Report" button is greyed out. | A required field is missing, the date range is invalid or too long, more than 200 monitors are selected, or you've hit your monthly report limit. | Check that the name is filled, between 1 and 200 monitors are selected, the range is valid and within your plan's max, and you have quota left this month. |
| The report card spins on "generating" and never finishes. | The generation was interrupted — a closed tab, a network drop, or a very wide window on a large account. | Leave it: after 30 minutes Enori flips a stuck report to failed, which frees nothing because it never used a slot. Generate again over a shorter period or fewer monitors. |
| "PeriodEnd cannot be in the future" after clicking Generate. | The end date is today (or later). A report covers whole UTC days and today isn't finished. | Set the end date to yesterday or earlier. |
| A rate-limit error after several reports in a row. | Report generation is limited to 5 per hour per account — it's an expensive operation. | Wait for the hour to roll over, or cover more monitors in one report instead of generating several. |
| The uptime cell is blank in the CSV / reads "no data" on screen. | Nothing was measured over that period. | See When a report has no data — usually a paused monitor. The blank cell is deliberate so a spreadsheet doesn't average a placeholder. |
| "PDF generation temporarily unavailable. Please try again." | A monitor name in the report uses a script the PDF can't draw — Korean (Hangul) is the known case. | Rename the monitor, or use CSV / the on-screen report, which are unaffected. |
| Scheduled reports stopped arriving. | The schedule was deactivated — most often because the plan no longer includes scheduled reports, or its last monitor was deleted. | Open Scheduled reports, check the schedule shows Paused, restore the plan or add monitors back, then Activate. See Scheduled reports. |
Reference: plan limits
| Reports per month | Scheduled reports | Max report period | Check detail kept | Public sharing | PDF export | CSV export | |
|---|---|---|---|---|---|---|---|
| Base | 3 | — | 365 days | 30 days | — | — | ✓ |
| Pro | 10 | 5 | 730 days | 60 days | ✓ | ✓ | ✓ |
| Business | Unlimited | 25 | 1095 days | 90 days | ✓ | ✓ | ✓ |
- Reports per month counts only the reports you generate by hand, in the UTC calendar month. Failed reports and reports produced by a schedule do not count.
- Scheduled reports is the number of schedules you can have, active or paused. Reports they generate do not count against the monthly figure.
- Max report period is your plan's uptime history — how far back a report can reach.
- Check detail kept is your data retention — how far back the downtime-periods table and per-check drill-down reach. See the two windows.
- Monitors per report: up to 200 on any plan.
Related documentation
- Service Level Objectives (SLOs) — track a reliability target continuously and get alerted on unhealthy burn rate, instead of pulling a report after the fact.
- Maintenance windows — declare planned work so it is excluded from your uptime and downtime figures.
- Billing and plans — what each plan includes, and how to upgrade.
Last updated: 2026-08-21. Feedback or corrections: support@enori.io