The board

Each area is rated healthy, watch, or problem. The board names the first area at problem, in this order, so an outage always outranks a slow page:

Open the Problem to see why. Client errors, failing requests, broken links, CSP blocks, and rage clicks list each page, endpoint, or blocked origin with whether it is new, back after a quiet spell, ongoing, a one-off, or quiet, live ones first; one-offs can be hidden. Broken links show the page that linked there, client errors the browsers that threw them, CSP blocks the directive and the pages, performance the slowest pages and devices, and third parties each slow origin with its time, share of loads, requests, and size. Every Problem’s notification carries an AI prompt that helps find and fix it; open a client error for its own.

• Under the Problem, every other area at watch or problem has a row: problems first, then watch, in the same order as above. Each shows why, a 14-day sparkline of what it watches (errors, broken hits, failed requests, or rage clicks a day; the p75 of the slowest speed reading; daily uptime; or the success rate), and for counted areas whether it is new, back, ongoing, or quiet.
• Open a row for the same detail the Problem’s dialog shows: each error, path, or endpoint with its own 14 days, the slow pages and devices, or the certificate findings. Clear works on problems; anything only being watched can be snoozed.
• When nothing else needs a look, the panel is one quiet line.

• Every path on the board opens that page’s own view: top pages, slow pages, broken links and where they were linked from, the pages that made a failing call, rage clicks, and a client error’s page. It follows the range you picked.
• It shows the page’s views by day and share of traffic; its p75 load, LCP, and INP beside the whole site’s; its client errors; the broken links visitors reached from it, or, if the page itself is missing, its hits and the pages that link to it; failing calls it made; rage clicks; and the page check covering it.
• Copy page prompt gives an AI assistant all of it with steps to fix it in your code. The URL holds the page, for example /dashboard?site=…&page=/pricing, so it survives a reload and can be shared with anyone who can see the board.

• Markers put a dashed line on the usage, uptime, response-time, and speed charts for each deploy or change, with what it was in the chart’s tooltip. An error, broken link, failing request, or rage-click page first seen on a marker’s day or the day after says “Started after the deploy on Oct 3”.
• Add a note or deploy under Changes with its date. To mark every deploy without lifting a finger, make the site’s deploy-hook URL there and add it as a webhook in GitHub (deployment status or push), Vercel, or Netlify, or call it from CI; or use the API with a write key.
• Each plan keeps 30, 300, or 1,000 markers per site, for as many days as it keeps counts; past that, the oldest drop off.

• Download CSV under Share and export saves the range as one row per day: pageviews, visitors, sessions, engaged visits, successes, p75 load, LCP, INP, and TTFB, client errors, broken hits, failed requests, rage clicks, homepage checks, uptime, and response time. The same file comes from the API.
• Read-only link shows the board to anyone holding it, without an account: the readings, issues, and charts, but no settings, actions, AI prompts, or install snippet. Tick Leave out visitor figures to hide visitors and sessions. The link is shown once; making a new one stops the old, and Turn it off ends it. It’s kept out of search engines, and it’s separate from the public status page.

• Clear a problem you fixed or expect, from its dialog. The board moves on to the next problem in line, and its emails and notifications stop. It comes back if it gets clearly worse (half as bad again, or a third less success for the funnel), and once it recovers, a recurrence counts as new.
• Snooze it for a day or a week to hide it until then, whatever happens. Areas only being watched can be snoozed from their row too. A cleared problem stays hidden while it eases back to watch.
• Ignore one client error (from its detail) or one broken path. It stops counting toward the error rate or broken hits, which suits browser noise like ResizeObserver warnings.
• An outage can’t be cleared or snoozed. A site that is down always shows and always alerts.
• Under the board, the cleared and ignored link lists everything you set aside, with when, and Restore puts it back.

The charts below the board follow the range picker: 7, 14, or 30 days, plus 90 days on Starter and a year on Pro. Past 30 days the usage chart shows a bar per week, as each week’s average day. How far back you can go depends on your plan; see Plans and limits.

• Under Load time, a line of p75 load, LCP, INP, or TTFB for each day of the range (each week past 30 days), over the bands the board judges by: good, needs improvement, and poor. By device splits load, LCP, and INP into desktop, mobile, and tablet; TTFB isn’t kept per device.
• Each point is estimated from that day’s timing buckets, assuming loads spread evenly within a bucket, so it moves as the mix shifts. It can differ a little from the board’s range figure, which takes the middle of the bucket. A day with fewer than 10 samples is a gap, not a guess.
• When a reading moves into a worse band and stays there for two points or more, the chart marks where: “Slower since Oct 3”. One bad day isn’t marked. Show the numbers lists every point with its band and sample count.

• Third parties and page weight, under Speed over time: the outside origins your pages load from (origin only, like widget.example.com), how long their requests run while a page loads (p75), how many page loads they’re on, requests per load, and KB when the origin lets browsers report it. Above them, what pages transfer at p75, and the heaviest pages. Each page load reports this once, a few seconds after it loads.
• Transfers count what came over the network, so a page whose files were cached reads light. Many outside origins hide their sizes from the page (they don’t send Timing-Allow-Origin); their KB shows as a dash, and the page’s total leaves them out.
• Countries, beside traffic sources: pageviews by the visitor’s country, as the two letters the hosting edge reports. PageHum never reads the IP address and keeps no city or region.

Compare, beside the range, lays the same number of days before the range over the charts: a dashed line on Usage and on Speed over time (for every load), and a change column on top pages, sources, countries, and devices (“+18%”, or “new” for one that wasn’t there before). It needs your plan to keep twice the range; when it doesn’t, a line says so instead of showing a quiet period that was never counted.

The strip under the board compares the last 7 days with the 7 before: pageviews, engaged visits, funnel conversion, and p75 load. Under 3% either way reads as flat.

• Each site shows the same five readings for the week, plus its LandingBoost score when linked, with the last 14 days under visitors, load, and uptime: visitors a day, p75 load, and the share of homepage checks that passed.
• Wall display (/dashboard/wall) puts every site on one dark screen in large type for a TV in the office: each site’s lamps, its week, and its one problem, with sites that need attention first. It refreshes every minute, keeps the screen awake where the browser allows, and has no motion beyond the lamps.
• Sort by newest, name, visitors, load, reachability, uptime, problem, or landing page score. Each starts the useful way (worst first for health, most first for traffic); press it again to flip. Empty readings sort last. The sort stays in the URL, for example /dashboard?sort=visitors&dir=desc, and is remembered for your next visit.
• Delete a site at the bottom of its board. Its counts, checks, and history go with it.