Skip to main content

Changes Tab: Reference

This page is the source of truth for the in-app Explain this panels on the Schema Explorer detail view's Changes tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

Changes are tracked for PostgreSQL, Microsoft SQL Server, MongoDB, and Oracle. Opening a change from the table leads to its detail page, which defaults to a seven-day window so deep-linked changes stay visible.

Total Changes​

The number of structural changes detected in the selected schema during the selected time window — additions, modifications, and removals combined.

How it's calculated​

  • Logstag detects changes by comparing consecutive schema inventory snapshots collected by the agent, so a change appears once the next snapshot lands: within about 10 minutes on PostgreSQL and MongoDB, and up to 4 hours on SQL Server and Oracle with default intervals.
  • The count is the change events recorded in the window. The four tiles here always show window totals — the filters below narrow the table, not the tiles.

Reading it​

Zero during a quiet period is the expected state; a burst that lines up with a deployment is normal and useful as a deployment audit. The number to chase is the burst nobody recognizes — structural change without a known deploy means someone or something is altering the schema outside the process.

Added​

The number of objects that appeared in this schema during the selected window — tables, indexes, views, routines, or other tracked object types created since the previous inventory snapshot.

How it's calculated​

  • An object present in the latest inventory snapshot but absent from the previous one is recorded as an addition.
  • On SQL Server, an object dropped and recreated under the same name between snapshots is recorded honestly as a Removed and an Added event — the recreated object is not the same object.

Reading it​

Additions are usually the healthiest change type — migrations creating what they should. Cross-check unexpected additions against the Change History's User column; an addition without a recognized owner or deploy window is worth asking about.

Modified​

The number of objects whose structure changed during the selected window — same object, different definition.

How it's calculated​

  • An object present in both consecutive inventory snapshots with differing structural metadata is recorded as modified.
  • Only structural differences count: on MongoDB, a collection is modified when its index count or collection options change — document counts and sizes drifting does not produce change events. On SQL Server, modification is detected through a structural fingerprint of the object's definition.
  • Opening a modified row shows the property-level differences — each changed property with its old and new value.

Reading it​

Modifications carry the most risk of the three types, because the object keeps its name while behaving differently — a column type change or a rebuilt index affects every query that touches it. The property-level diff in the row detail tells you exactly what to review.

Removed​

The number of objects that disappeared from this schema during the selected window.

How it's calculated​

  • An object present in the previous inventory snapshot but gone from the latest one is recorded as a removal.
  • On SQL Server, a drop-and-recreate under the same name records as a Removed plus an Added pair rather than a modification.

Reading it​

Removals deserve the fastest review of the three types: a dropped table or index is either a planned cleanup or an incident, and nothing in between. If a removal surprises you, the object's last-known definition is preserved in the change record — open the row detail before anyone recreates it from memory.

Change History​

Every structural change detected in the selected schema and window, newest first. Click a row to open the full change detail, including property-level old and new values for modifications.

Columns​

  • Timestamp — when the change was detected.
  • Object — the object the change belongs to.
  • Type — the object type. The available types depend on the engine: PostgreSQL tracks tables, columns, indexes, views, functions, sequences, constraints, foreign keys, and permissions — a grant or revoke appears here as a change; SQL Server tracks tables, views, procedures, functions, sequences, synonyms, and triggers; MongoDB tracks collections; Oracle tracks its object types at an aggregate level.
  • Change — Added, Modified, or Removed.
  • User — the owner or schema context recorded with the change, when available.
  • Description — a summary of what changed (hidden by default; enable it from the column menu).

How it's calculated​

  • Changes are derived by comparing consecutive schema inventory snapshots, so detection lags collection: within about 10 minutes on PostgreSQL and MongoDB, up to 4 hours on SQL Server and Oracle with default intervals.
  • Oracle rows are aggregates, not individual objects: Oracle inventory is collected as object counts per owner and type, so a row like HR.TABLE means the count of HR's tables changed — the object-name filter does not apply to Oracle.
  • Very broad windows are capped at 5,000 change records; when the cap is hit, narrow the window for an exact set.

Reading it​

Filter by Change = Removed first after any incident. On MongoDB, remember index changes appear as a Modified event on the collection (the index count changed) rather than as separate index rows. And on PostgreSQL, this table doubles as a lightweight permission-change audit — grants and revokes are first-class change records here.