Grafana
Grafana shows whether things are working. The question it most often prompts — "is something wrong" — is asked by people who will never look at a dashboard.
Grafana shows whether things are working. The question it most often prompts — "is something wrong" — is asked by people who will never look at a dashboard.
What Grafana holds, and why that matters here
Grafana is the operational monitoring layer in a great many organisations: system health, service metrics, alert state. It is built for engineers watching systems, and it does that well.
The wider organisation asks a simpler question — is it working, is it slow, is that why my thing failed — and currently asks it of an engineer.
- Service health — current operational state.
- Metrics — the measurements over time.
- Alerts — what is firing and what has recently fired.
- Dashboards — assembled operational views.
- Annotations — recorded events such as deployments or incidents.
Questions Elbi can answer from Grafana
Is everything working?
Current health, answered plainly to a non-engineer.
Is there an incident?
Alert state, which answers a large share of "is it me" questions.
Was there a problem earlier?
Recent alert history, which explains something a user noticed.
Is it slow right now?
Current performance metrics in plain language.
When was the last deployment?
Annotations that frequently explain a change in behaviour.
Has this recovered?
Whether a known issue is resolved.
How Elbi reads Grafana
- Services get plain namesEngineers name alert rules and panels for engineers. The connection starts from a map written in ordinary Arabic and English — "the payments service", "the mobile app login" — each linked to the alert rules and panels that say whether it is healthy.
- Alert state firstMost questions are answered from Grafana Alerting: which rules for that service are firing or pending, and since when. That is a far more reliable signal of "is something wrong" than reading a raw metric.
- Annotations for contextDeployments and incidents recorded as annotations explain a lot of "it was fine this morning". The assistant can say that a release went out shortly before the problem started, without drawing conclusions from it.
- Metrics in plain wordsWhere a figure helps — response time, error rate, queue length — it is given with a comparison people understand: normal, elevated, well above usual. Nobody outside operations needs a percentile.
- Depth depends on who asksAn engineer can be given rule names and values; the helpdesk gets service status and start time. Customers, where you allow them to ask at all, hear only the status your organisation has declared.
- Diagnosis stays with engineersThe assistant reports what Grafana shows. Cause, fix and expected recovery are for the people working the incident, and it says so rather than speculating.
Scope and control in Grafana
| Direction of access | Read-only. The assistant does not silence, acknowledge or edit alerts, and does not change dashboards, data sources or annotations. |
|---|---|
| Service account | A Grafana service account with the Viewer role and a token created by your administrators. Tokens can be given an expiry, rotated or revoked from Grafana, and the account can be disabled outright. |
| Data sources | In open-source Grafana a Viewer can query the data sources in its organisation. Narrowing that per data source uses data source permissions in Grafana Enterprise or Grafana Cloud, or a separate organisation holding only what the assistant needs. |
| Logs | Left out by default. Logs are where personal data and secrets tend to end up, and status questions do not need them. |
| Where data goes | Readings are used to answer and are not stored: conversation content is destroyed within 24 hours, usually when the conversation ends, and no external AI service sees it. |
| If Grafana is down | The assistant says monitoring cannot be reached. It never reads silence as "everything is fine". |
What this replaces
The distinctive value is translating operational state for non-operational people. During an incident, engineers are occupied and everyone else is asking them what is happening — which is precisely the worst moment for that interruption.
An assistant that answers "yes, there is a known issue with this service, it started at this time, it is being worked on" removes a large volume of contact at exactly the moment capacity is scarcest.
It also helps support teams. A customer reporting a problem may be experiencing a known incident, and matching the report against current alert state prevents a diagnostic conversation that was never going to find anything.
Who asks Grafana questions through Elbi
Support teams
Matching customer reports against known incidents.
Internal helpdesk
Answering "is it just me" without interrupting engineers.
During incidents
Status to the wider organisation while engineers work.
Management
Operational state without a dashboard.
Getting value from Grafana alerts
Start with the services the rest of the organisation actually notices: login, payments, the customer app, email. For each, "is it working right now?" answered from alert state covers most of what the helpdesk is asked during a bad hour.
"Was there a problem earlier?" comes next. Recent alert history and annotations let the assistant tell someone that the slowness they saw was a known issue that has since cleared, which closes a ticket before it is opened.
The quality of all of this depends on the alert rules. A service whose alerts fire constantly and are ignored will make the assistant report problems that engineers know are noise. Cleaning up those rules is worth doing first, and engineers usually welcome the excuse.
What connecting Grafana involves
- Write the service mapList the services people ask about, in the words they use, and link each to the alert rules and panels that describe its health. Operations owns this map.
- Review the alert rulesRemove or fix rules that fire without meaning anything, and make sure each mapped service has at least one rule that reflects what users experience.
- Create the service accountAn administrator creates a service account with the Viewer role, issues a token with an expiry, and records who holds it.
- Limit what it can queryRestrict folders and, where your edition supports it, data sources, so the account sees the dashboards and alert state in scope and not the logs or security panels.
- Agree audience wordingDecide what the helpdesk may hear, what managers may hear, and whether customers may ask at all. Write the customer wording with whoever owns incident communication.
- Test during a drillTrigger a test alert or use a planned maintenance window, and check what each audience is told from start to recovery.
Personal and security data in Grafana
Metrics rarely identify anyone, but labels and logs can: user IDs, email addresses and IP addresses find their way into both. Under the Saudi Personal Data Protection Law there is no need for a status assistant to touch them, which is why logs are out of scope and labels are reviewed before a panel is added to the map.
Security alerts deserve separate treatment. An alert that describes an attack in progress is useful to the security team and harmful in the wrong hands, so those rules belong to a narrower audience, or outside the connection altogether.
Grafana's own options, and where an assistant fits
Grafana already pushes alerts to people: contact points send notifications to email, chat tools and paging services, and notification policies route each alert to the right team. Many organisations add a public status page, updated by whoever leads an incident, for customers and staff alike.
Those channels are for people who are told. An assistant is for people who ask — the account manager whose client has just phoned, the helpdesk agent looking at a pile of identical tickets — and it answers from the same alert state the engineers see.
What goes wrong is exposure. Raw alert names, internal hostnames and half-understood metrics shown to non-engineers create confusion during the very incident they are meant to clarify; the service map and audience wording exist to prevent that.
What operations teams see with Grafana connected
Common questions
It reports what is firing and when it started, in plain language. Diagnosis stays with engineers.
That is when it is most useful — it absorbs the status questions that would otherwise interrupt the people fixing the problem.
No. It answers questions about state; alerting continues to do its job.
No. A Viewer service account reads dashboards and alert state; it cannot change Grafana or reach the systems Grafana monitors. You hold its token and can revoke it at any time.
No. Handling alerts is an engineering decision, and the connection is read-only by design.
The assistant says it cannot reach monitoring, rather than reporting that all is well, and offers to pass the question to the operations team.
Connect Grafana to Elbi
Service status and alert state in plain language for the people who ask, in Arabic and English.