Error log

The Error log page reads the SQL Server error log — and, on the same page, the SQL Server Agent log — straight from the monitored instance. Nothing is copied into the monitoring database: SQL Server already keeps and rotates these files, and a second copy would only be a second thing to keep in sync.

What the levels mean

Every line is classified as it is read, so you can jump to what matters instead of scrolling. The classification uses two signals and takes the more serious of the two.

Severity alone would be misleading: a failed backup is logged at severity 16, which the severity table calls a mere warning. The message text is read as well, and whichever signal is more serious wins.

Reading a large log efficiently

The time range and both search boxes are applied inside SQL Server, not in the browser. A narrower query is genuinely cheaper — it never transfers the rest of the file. The two search boxes are ANDed: Login failed plus sa finds failed logins for that account only.

Only the newest 2 000 matching lines are shown. When that limit is hit the page says so explicitly, because a silently truncated log is worse than no log at all.

Two views, two questions

The View selector switches between them:

• Live from server reads the file on the instance. Current to the second, unfiltered by our opinions, and gone the next time the service restarts.
• Archived (harvested) reads what the monitor kept. A background service copies every line at or above the configured level into the monitoring database every few minutes, so this view reaches back past service restarts and past however many log files SQL Server has since rotated away.

Neither replaces the other. The live view is the one to trust when you are looking at something happening right now; the harvested view is the only one that can answer "what did this server say three weeks ago".

The badge next to the table header tells you whether harvesting is actually working — harvested 4 min ago, not harvested yet, or harvest failing with the reason. An empty table under a red badge means nobody could read the log, which is a very different statement from a quiet server.

Alerts

Harvested entries at or above the alert level (default Error) raise an alert through the normal alerting machinery: severity routing, notification channels, maintenance windows and acknowledgement all behave as they do for any other alert.

Two deliberate behaviours:

• One alert per level per burst, not one per line. A stack dump is a dozen lines inside one second; a dozen pages for one incident is how an on-call rota learns to mute a product. The alert carries the worst line as its sample and the number of occurrences.
• The first harvest of a server stores nothing. It records a watermark and stops. Switching monitoring on must not import weeks of history and then page somebody about a restart that happened in July.

Two rules are created automatically per server, Error log: Error and Error log: Critical, so you can route Critical to PagerDuty and Error to email, or disable one without the other. They are ordinary rules on /settings/alerts — edit them like any other.

Error-log alerts describe a point in time rather than a condition, so they do not resolve themselves. Acknowledge one once you have dealt with it.

What a critical event carries with it

Click any harvested row to open its detail panel. For Critical entries it holds two things the table cannot show.

The surrounding log lines. The level filter that keeps the table readable is also what throws away the lines that explain a critical event — a stack dump keeps its Stack Dump being sent to ... header and loses Input Buffer 255 bytes - SELECT ..., the statement that caused it. So on a critical the monitor goes back and re-reads a couple of minutes either side unfiltered, and stores that block with the event. The event's own line is highlighted inside it.

If the instance restarted before the monitor got there, the log has already rolled over and the block cannot be recovered. The panel says so rather than showing an empty box — and it distinguishes that from a read that failed on permissions, because one is the server's doing and the other is ours.

What else happened. A timeline of everything already recorded within ±15 minutes: configuration and DDL changes, deadlocks, blocking chains, other alerts, plus CPU, memory and connection counts from the nearest sample. Each entry is stamped relative to the event — −3 min before, +40 s after — because that is the question being asked. No extra queries reach the monitored server for this; it is all data the product had already written down without ever putting it next to the event.

Archived logs

SQL Server starts a new log file on every service restart and whenever sp_cycle_errorlog runs, keeping six archives by default. The File picker lists what is currently on disk. If you need more history than that, raise the number of retained logs in SQL Server Management Studio (Management → SQL Server Logs → Configure).

Permissions

Reading the log needs two grants that the usual monitoring rights do not include. Both procedures live in master, so the login also needs a user there — that missing user is the step people skip:

-- On each monitored instance, as sysadmin:
USE master;
CREATE USER [monitoring_login] FOR LOGIN [monitoring_login];   -- required: the procs live in master
GRANT EXECUTE ON sys.xp_readerrorlog  TO [monitoring_login];   -- reading the log
GRANT EXECUTE ON sys.xp_enumerrorlogs TO [monitoring_login];   -- listing the archives

securityadmin membership works too, but it grants far more than this needs — it can create logins and reset passwords. Prefer the two grants.

Note that the sp_readerrorlog and sp_enumerrorlogs wrappers cannot be used with the narrow grants: they carry an internal securityadmin check. The monitor therefore calls the underlying extended procedures directly.

Without the permission the page reports exactly what to grant rather than showing an empty log — an empty log and an unreadable one are very different statements about a server.

Azure SQL Database

There is no instance-level error log to read, so the page says so instead of failing. Managed Instance and on-premises instances work normally.