A website status page needs availability history because its current status cannot explain earlier interruptions or recurring faults. A status page with website availability history answers two different questions: is the site responding now, and how consistently has it responded over time? A 90-day view gives clients and web teams useful context, provided they understand what was checked and where the record has gaps.
For an agency, that distinction matters when a client reports a problem that has already cleared. Opening the website and finding it working does not disprove their experience. The useful next step is to compare the reported time with the monitoring record, then explain what the evidence supports.
Current status and availability history do different jobs
Current status is a summary of the latest monitoring results. It helps someone decide whether there is a problem needing attention now. It should be read alongside the time of the last check: a successful result is evidence about that check, not a continuous guarantee of service.
Availability history adds the time dimension. It shows whether detected interruptions were isolated, repeated or concentrated in a particular period. A site can be responding now while its recent record still warrants investigation. Equally, one current outage does not establish that the service has been unreliable for months.
Keep three things distinct: the current result, the historical availability summary and the incident explanation. The first describes the latest observation. The second summarises recorded behaviour. The third explains the known impact, response and cause. Neither a green banner nor a coloured history strip can replace the other two.
What a 90-day view helps you see
Ninety days is a useful review window because it extends beyond the most recent incident without requiring readers to inspect a long archive. It can put several releases, maintenance windows and client reporting periods in view. It is a practical window, not a special threshold at which monitoring becomes conclusive.
A daily strip makes it easier to locate affected dates. Start there, then inspect the underlying records where available. One marked day might contain a single interruption or several separate failures. Two days with the same visual state may have very different durations and commercial consequences.
Consider a hypothetical comparison: one website has a single hour-long interruption, while another has twelve five-minute interruptions. Their total unavailable time is identical, but the second pattern suggests repeated disruption. That should prompt different questions about intermittent failures, scheduled jobs or repeated changes. The summary alone does not identify which explanation is correct.
A rolling window also needs care. An old incident eventually leaves the visible period, so an improving headline figure does not necessarily mean a technical fix has worked. Check whether the improvement reflects fewer new failures or simply the passage of time.
Read the percentage with its measurement rules
An availability percentage needs a denominator and a method. A time-based calculation divides available monitored time by the included monitoring period. A check-based calculation divides successful checks by included checks. These approaches can produce different results, particularly when checks are irregular or monitoring has gaps.
Before using a figure in a client report, establish the following:
- Scope: which URL or service was tested, and what response counted as successful?
- Timing: how frequently were checks made, and what rules confirmed failure and recovery?
- Coverage: when did monitoring begin, and were there pauses or missing results?
- Treatment: were maintenance periods included, excluded or labelled separately?
A new monitor cannot establish what happened before it started collecting data. Missing observations should not silently become successful observations. If only part of a 90-day window has been monitored, describe that coverage clearly rather than presenting it as a complete quarter.
Scheduled checks also leave intervals between observations. A short failure may occur entirely between checks, while the exact start of a longer failure may precede its first detection. Use terms such as 'first detected' and 'recovery confirmed' when those are what the timestamps actually establish.
Use history to investigate, not to guess the cause
Start with the affected dates and compare their detailed timestamps with deployment records, hosting events and application logs. Keep the time zone consistent. A client report in local time and an incident record in UTC can otherwise appear to describe different events.
Repeated failures near the same scheduled task justify investigating resource use and task behaviour. Failures across several sites at similar times justify checking shared infrastructure. Neither pattern proves a cause: the next step is to find supporting evidence in the systems involved.
Also check what the monitor cannot see. A homepage may respond successfully while a booking form or checkout fails. A clean availability record therefore does not establish that every visitor could complete every task. Where a complaint concerns a particular journey, investigate that journey rather than relying on the homepage result.
If the site is currently unavailable, prioritise restoring service and communicating the known impact. The client website outage response plan covers that immediate work. Historical analysis becomes useful once it supports diagnosis or helps prevent a repeat.
Explain the record without dismissing the client
Client reporting should connect the observation to the action. State what monitoring detected, the affected service, when recovery was confirmed and what remains unresolved. Separate a confirmed cause from a working theory. Do not turn a high availability figure into a reason to minimise a genuine interruption.
For example, a hypothetical update could say: 'Monitoring detected an interruption on Tuesday and confirmed recovery later that morning. The site is responding now. We are comparing the incident with the hosting logs, and the cause is not yet confirmed.' That is more useful than either 'everything is green' or an unsupported diagnosis.
Keep a dated incident note outside any rolling summary when the event needs follow-up. Record the evidence, responsible person and next action. A daily strip helps readers find the interruption; the note preserves what the team learnt and what still needs doing.
What to look for in a status page
Choose a page that makes current problems easy to find while keeping historical context visible. Assess whether readers can understand the dates, measurement scope and missing-data states. Check access controls and decide which technical findings belong in public, which are suitable for clients and which should remain internal.
TLDTrack provides one status page per monitored site, with a current-status banner and a 90-day availability strip containing one block per day. Check visibility is configurable per page, and pages can be password-protected.
Those presentation choices do not remove the need to explain the monitoring scope. Before sharing a page, view it as a recipient would. Confirm that the visible checks match the service being discussed and that any accompanying message does not imply broader coverage than the monitoring provides.
Make the history part of the review
Assign someone to review availability history before each client reporting cycle and after a significant incident. Look for repeated interruptions, incomplete coverage and unresolved follow-up actions. Compare equivalent periods and note changes to the monitored URL, check frequency or success criteria before drawing conclusions.
For each affected day, aim to answer three questions: what was detected, what was done and what happens next? If the history reveals a recurring fault, assign the investigation rather than merely carrying the same warning into another report. A recovered website needs a current green status; a repeated failure needs an owner and a corrective action.
