Incident History
Incident history is the complete, time-ordered record MonitorUrs keeps of every check and state change. It combines detailed per-check probe logs with logged server telemetry and recorded alerts, so you can review past downtime, recovery events and response times for any monitor at any time.
Last updated: June 2026
Why incident history matters
An alert tells you something is wrong right now, but it rarely tells you the whole story. When the dust settles after an outage, the questions start: when exactly did the site go down, how long was it unreachable, what did the server return while it was failing, and were there warning signs in the hours beforehand? Without a durable record, those answers are lost the moment the incident ends, and the same problem is free to happen again.
Incident history solves that by keeping every check and every state change on file. Instead of relying on memory or screenshots, you have an objective timeline you can scroll back through. That record is what turns a stressful, ambiguous outage into something you can measure, explain to stakeholders and learn from — and it is the foundation for spotting slow degradation long before it becomes downtime.
What MonitorUrs logs
MonitorUrs records history at several levels, so you can move from a high-level "was it up?" question all the way down to what a single check returned at a single moment:
- Per-check probe logs — every time a probe runs, it writes a log entry capturing the result, a result description, the response time in milliseconds, the HTTP status code, the response body length and a timestamp. This is the granular, check-by-check record of what happened, and the result description explains which validation caused a failure.
- Server telemetry history — the metrics reported by the agent (CPU, memory, disk and drive usage, and network throughput) are logged over time with timestamps, while each server's current online/offline status and last-seen time are tracked continuously.
- Alert records — when a downtime alert or a server metric-threshold alert fires, it is recorded with a timestamp, giving you a dated record of every notification MonitorUrs sent.
All of this data is stored in the platform's database, so the history is there whenever you need to review it. Together these give you a complete history of checks, telemetry, incidents, recovery events and response times.
What each probe check log records
Each individual check stores a structured set of fields. Reading them side by side is what lets you reconstruct exactly what the server returned at a given moment:
| Logged field | What it tells you |
|---|---|
| Result | Whether the check passed or failed overall, the headline outcome for that run. |
| Result description | A human-readable note explaining the outcome, useful for understanding why a check failed. |
| Response time (ms) | How long the request took, in milliseconds, so you can track performance over time. |
| HTTP status code | The status code returned by the server (for example 200, 404 or 503). |
| Response length | The length of the response body, helping you spot truncated or empty responses. |
| Timestamp | Exactly when the check ran, anchoring every entry on a precise timeline. |
Reviewing downtime timelines and recovery
MonitorUrs gives every incident a defined beginning and end by combining two records: the downtime alert — sent when a probe crosses its failure threshold or a server stops reporting telemetry — and the recovery alert sent when service is restored. Reading those against the per-check probe logs lets you reconstruct the full downtime timeline: the last healthy check, the first failure, the status codes and descriptions recorded throughout the outage, and the moment recovery was confirmed.
This pairing answers the questions that matter most after an outage — how long was it down, and what was the server actually returning while it was failing — without guesswork. It complements live uptime monitoring, which watches availability in real time, by preserving the detailed after-the-fact record.
Using response-time history to find trends
Every check stores its response time in milliseconds alongside a timestamp, so the accumulated history doubles as a performance record. Looking back over that history, you can see whether a site has been getting steadily slower, compare response times before and after a deployment, or notice that latency was creeping up in the hours leading to an outage. Slow responses are often the earliest warning that something is wrong, and the history is where those patterns become visible. For a focused view of this signal, see response-time monitoring.
Post-incident review and auditing
A durable log is what makes a meaningful post-incident review possible. After an outage, the team can walk through the per-check logs and their result descriptions to establish a factual sequence of events: what the server returned, which validation caused the failure, when the failure threshold was crossed and when recovery was confirmed. Because the data lives in the platform database rather than in a transient alert, it is available for review and auditing well after the incident is closed. That same record supports demonstrating to clients or stakeholders that a service was monitored and how it behaved over a given period.
Common use cases
- Post-mortem analysis — reconstruct an outage step by step from the per-check logs and alert records to understand exactly what happened and when.
- Performance tracking — use accumulated response-time history to confirm whether a change made a service faster or slower.
- Agencies reporting to clients — point to a concrete history of checks and incidents as evidence that a client site was being watched.
- Debugging intermittent failures — review the per-check logs and result descriptions to see what keeps failing, even when the overall site looks fine.
How incident history fits the dashboard and alerting
Incident history is the long-term memory that sits behind the rest of the platform. Alerts handle the immediate moment, telling you the instant a check fails, while the real-time status dashboard shows what is happening right now. Incident history fills in everything that came before: the detailed past record of checks, server telemetry and recorded alerts. Every probe you run — whether it is website monitoring or any other check — continuously feeds this history, so the dashboard tells you the present while the logs explain the past.
Frequently asked questions
What is incident history in MonitorUrs?
Incident history is the complete record MonitorUrs keeps of every check and state change. It includes detailed per-check probe logs, logged server telemetry and recorded alerts, so you can review past downtime, recovery events and response times for any monitor.
What does each probe check log record?
Each probe check writes a log entry with the result, a result description, the response time in milliseconds, the HTTP status code, the response body length and a timestamp. Together these entries form a full, time-ordered history of every check.
How long is incident history kept?
Check logs, server telemetry and alert records are stored in the MonitorUrs platform database so you can review them after an incident. The history accumulates over time, giving you a long-term record for trend analysis and post-incident review.
Can I see exactly when a server went down and came back?
Yes. MonitorUrs sends a dated downtime alert when a server stops reporting and a recovery alert when it comes back, and the per-check logs show the failing checks in between, so each incident has a clear start and recovery point.
How does incident history help with response-time trends?
Because every check stores its response time in milliseconds with a timestamp, the accumulated history lets you spot slowdowns, compare performance before and after a change, and see whether response times were degrading before an outage.
Where do I see current status versus past incidents?
Current status is shown on the status dashboard, while incident history gives you the detailed past record of checks, server telemetry and recorded alerts. The two work together: the dashboard for what is happening now, the logs for what happened before.