Operations | Monitoring | ITSM | DevOps | Cloud

On 8 October 2026 Elastic announced the private preview of Elastic nightshift AI SRE, an AI agent built into Elastic Observability that detects and investigates issues and shows its reasoning. It is a sign of where observability tooling is heading: more of the first hour of an incident handled by an assistant that reads your telemetry. Short answer: Logit.io does not offer an autonomous AI SRE agent.

The ingestion card on your Logit.io dashboard has a 24h / 7d toggle for Logs and Metrics, hourly log counts built from counter increases and a dotted line for the hour that is still filling in. Those three changes decide whether a dip on the chart is a real problem or just the clock.

FortiGate, PAN-OS and Zscaler now each have a six-dashboard pack in the Dashboard Library, live on every Logs stack. If your firewall logs already arrive as parsed module fields, the Library pre-selects the matching pack. If they don't, it won't, even when the firewall has been sending syslog for years. This post is about that gap: which parsed fields each pack reads, the Filebeat module settings that produce them, and the API checks that tell you whether the dashboards will fill before you install them.

Open the Dashboard Library on a Logs stack that already receives Nginx logs and a few cards come up ticked with a green Data detected badge. Others in the same pack sit there unticked. That isn't random. Before it shows you anything, the Library checks what your stack actually holds and pre-selects only the dashboards it expects to fill.

CloudWatch already holds the lines from your Lambda, ECS task, or unified agent. The first useful win on Logit.io is not a migration spreadsheet. It is one Log Group, the documented Lambda shipper posting to this stack's API, and rows in OpenSearch Dashboards Discover that show logGroupName, logStreamName, and message. If you are still proving that a Logs stack can accept anything at all, start with First Logs on Logit.io; this post assumes CloudWatch is the source and the Stack API is the pipe. Contents.

EU buyers asking for Hosted OpenSearch with data residency usually mean something precise: indexes and cluster storage should land in a European data centre that lines up with GDPR expectations and the geography named in the DPA — not a US default that security later has to unwind. On Logit.io that choice is an account-level data storage region, not a free toggle on every stack. Get the first stack right and every later OpenSearch or log stack in that account follows.

Procurement teams asking for UK-hosted OpenSearch usually mean something concrete: indexes and cluster storage should land in a UK data centre, not wherever a vendor’s default region happens to be. On Logit.io that choice is an account-level data storage region, not a free toggle on every stack. Get the first stack right and every later OpenSearch or log stack in that account follows. Get it wrong after go-live and you are looking at a second account, not a silent migrate button.

Distributed tracing has become essential for understanding the performance and behavior of modern microservices architectures. As applications become more complex with multiple services communicating across different environments, traditional logging and metrics alone are insufficient for debugging performance issues and understanding request flows.

Server monitoring is essential for organisations relying on digital infrastructure. It tracks performance, availability, and health to ensure smooth operations. Without it, businesses face risks like downtime, poor performance, and security threats.

Audit logs, otherwise referred to as audit trails, are detailed records that document activities or a sequence of activities or events. Typically, they deal with the usage of systems, applications, and/or networks. They are crucial in ensuring security, compliance, and operational oversight and enable users to keep track of the history of all actions executed and who has done what and when.