Security

Two products, two data flows. Here are both.

Abendly has a hosted log analyser you can use today and a monitoring agent that runs in your environment. They handle data differently, so this page describes each one on its own: what moves, where it goes, what is kept and for how long.

Available now

Log Analyser (hosted service)

The analyser is a hosted service: your sanitized log is sent to our API, which passes it to the AI provider you connect in Settings, with your own key. Sanitization happens first, in your browser, and you see the result before anything is sent.

Your side your browserAbendly our hosted servicesProvider your AI provider (Anthropic for free-trial analyses)

  1. Your browser

    Sanitize

    Hostnames, IPs, queue managers, channels, queues and user IDs are replaced with labels like [QM_1]. No network call is made during this step.

  2. Your browser

    Review

    You see the sanitized text before sending. The label map that turns labels back into names stays in your browser.

  3. Abendly API

    Receive

    Signed-in users only. The API (on Render, US) receives the sanitized text, the detected error codes and the platform.

  4. Your AI provider

    Analyse

    The API drops routine and repeated log entries, then sends the sanitized text to the provider you connected, with your key, under your agreement with them. The one exception: a free account's trial analyses go to Anthropic on Abendly's account.

  5. Abendly database

    Store

    The result and the first 2,000 characters of the sanitized log are saved to your account (Supabase, US-East).

What is stored

  • Your account: email address and password (hashed by Supabase Auth), plan and usage counts.
  • Your AI provider settings: provider, model and endpoint, and your key, encrypted (AES-256-GCM) before it is stored. The key is never shown again or logged.
  • Token counts for each call to your provider: provider, model, and input and output tokens, with no content. They're listed on your dashboard.
  • Each analysis: the diagnosis, fix commands and timeline, plus the first 2,000 characters of the sanitized log.
  • A shared fingerprint per analysis: error code, platform, MQ version, channel type and fix parameter, with no link to your account. These build a knowledge base that improves analyses for everyone.
  • Usage events: which features were used (for example, that a sample log was loaded), with your account ID if you're signed in.

What is not sent

  • The raw log. Only the sanitized text leaves your browser.
  • The label map. It's kept in your browser's storage and never sent to the API.
  • Card details. If you buy a plan in the app, payment is handled by Stripe; we keep only a Stripe customer reference.
  • A note on sanitization: it's pattern-based, so an unusual identifier format can slip through. That's why you review the sanitized text before sending it.
Design-partner pilot

Monitoring Agent (runs in your environment)

The monitoring agent is available as a design-partner pilot on one queue manager. It is designed so that raw logs and identifiers stay inside your environment, and it can see everything and change nothing.

  1. Your queue manager

    Read

    The agent reads queue depths, channel status, MQ events and error logs with an inquire-and-display service account.

  2. Your environment

    Strip

    Identifiers are replaced with stable labels inside your boundary, before anything is reasoned over.

  3. Your AI provider

    Reason

    Your own provider and key: Anthropic, Azure OpenAI, Amazon Bedrock, IBM watsonx, or a self-hosted model. Not ours.

  4. Your environment

    Map back

    Labels are mapped back to real names inside your environment, where the label map lives.

  5. Your console

    Surface

    Findings appear in the console, and through a webhook you create in your own Slack workspace, with the cause, confidence and MQSC fix. PagerDuty is on the roadmap.

service account · scope
  • Allowed: DISPLAY CHSTATUS
  • Allowed: DISPLAY QLOCAL / QDEPTH
  • Allowed: read SYSTEM.ADMIN.*.EVENT
  • Never allowed: STOP / START CHANNEL
  • Never allowed: ALTER / DEFINE / DELETE
  • Never allowed: PUT / GET / BROWSE application messages
Enforced by OAM on distributed and RACF on z/OS. You provision it, and you can revoke it.

How it differs from the analyser

  • No Abendly servers in the loop: the agent, the label map and the model all run under your control.
  • Your AI provider is your vendor, under your key and your data agreements. Model usage is billed to your account.
  • Air-gapped is possible with a self-hosted model.
  • Pilot terms in writing: the deployment, and any access you choose to give us during the pilot, are agreed at kickoff.
Data retention

What is kept, for how long, and how it's deleted.

Today nothing is deleted on a timer: data is kept until it's deleted on request. When a fixed period is set for any row below, this table will say so.

Retention for the website and the log analyser. The monitoring agent keeps its data in your environment, under your retention rules.
DataWhereKeptHow deletion works
Account: email, hashed password, plan, usage countsSupabaseWhile your account existsOn request to privacy@abendly.io.
Analyses: results and the first 2,000 characters of the sanitized logSupabaseWhile your account existsDeleted with your account, on request.
Your recurring-pattern and label statisticsSupabaseWhile your account existsRemoved automatically when your account is deleted.
Shared fingerprints: error code, platform, MQ version, channel type, fix parameterSupabaseIndefinitelyNot linked to any account, so they can't be traced back to you or deleted per person.
Usage eventsSupabaseNo automatic expiry yetDeleted with your account, on request.
Your AI provider settings and encrypted keySupabaseUntil you remove the provider, or your account is deletedRemove provider in Settings deletes it at once; it is also deleted with your account.
Token counts per call (no content)SupabaseWhile your account existsDeleted with your account, on request.
Website form submissionsNetlifyNo expiry set by usOn request to privacy@abendly.io.
API server logs: requests and errorsRenderRender's log retention for our planExpire on Render's schedule.
Follow-up questions in an analysis chatSent to your AI providerNot stored by AbendlyYour agreement with your provider governs its copy.
Label mapsYour browser onlyUntil you clear this site's data in your browserYou control it; we never receive it.
Posture

Where we stand, stated exactly.

We'd rather under-claim than over-claim. Badges come back when the substance behind them exists.

In progress

SOC 2 Type II: in progress, target Q4 2026.

Not yet certified. We'll say so here when the report exists.

In place

Privacy requests (access/deletion) honoured. Contact privacy@abendly.io

Ask for a copy of your data or for its deletion at privacy@abendly.io. See the privacy policy.

On request

Subprocessor list shared with customers.

We use a small set of providers to host the website and run the analyser. The current named list is in our Data Processing Addendum, and we give notice before it changes. Ask at privacy@abendly.io.

In place

Encryption in transit

The website and the API are served over HTTPS only.

In place

Encryption at rest

Data stored in our database is encrypted at rest by Supabase.

In place

Data residency

The API runs on Render in the US; the database is on Supabase in US-East. Ask us if you need a different region.

Questions

Running it in your estate.

How does licensing work in an air-gapped estate?

Exactly as it does anywhere else: offline. Your licence key is a signed string that records your tier, the queue managers and platforms it covers, and its term. The agent checks the signature inside your environment against a public key built into the product. Checking it needs no network connection, and nothing is sent anywhere: no call home, no telemetry.

A renewal is a new key, entered the same way, so it needs no network access either. The console warns you for 30 days before the licence expires. If it does expire, new analysis stops, but the console keeps showing every finding already collected: you are never locked out of your own data. Your tier decides which releases you can install: Full Support takes every release and knowledge-base update; Maintenance takes security and critical patches.

The agent is in a design-partner pilot today.

What will the collector cost my hosts and queue managers?

These are the design targets the collector is being built to, to be validated in the pilot. They are not measured benchmarks. The agent is in a design-partner pilot, and each pilot measures the real figures.

The collector reads each queue manager with one sweep per interval: a handful of wildcard DISPLAY commands, not one command per queue. The interval is 60 seconds by default and can be set from 15 to 300. A sweep costs about 8 ms plus 0.012 ms per queue on the collector. Event queues, and SMF statistics on z/OS, are read as they arrive rather than polled.

For a reference estate of 3 queue managers and 1,000 queues, the targets are:

  • about 0.02% of one core per queue manager on the collector host, ~0.1% in total;
  • 150–250 MB of memory, and a few MB a day of retained telemetry per queue manager;
  • at the fastest setting (15 seconds), still under ~0.5% of one core for the whole estate.

On your queue managers, each sweep is handled by the command server. The budget is under 0.1% of one engine per queue manager at the default interval. On z/OS that is about 30 CPU seconds a day per queue manager; the pilot measures the actual MSU impact and puts it in the pilot report.

The AI model is called only when something deviates, so model use grows with incidents, not with the size of your estate.

How does it connect to MQ?

Over your internal network, using standard read-only interfaces: PCF inquire commands, the SYSTEM.ADMIN event queues MQ already emits, and the error logs. MQ is never exposed to the internet. The connection is ordinary MQ client work your own admins can review.

Does it cover z/OS as well as distributed?

Both. On distributed it reads AMQERR logs and PCF; on z/OS it reads CSQ messages and queue-sharing-group state including CF structures. Authority is governed by RACF on z/OS and OAM on distributed. You provision the scope, and you can revoke it at any time.

What if a recommendation is wrong?

Every finding ships with a confidence level and the specific signals it's based on, so your engineer can judge it before acting. Because nothing is ever auto-executed, a wrong recommendation is a suggestion to decline, not an action to undo. The human is always the one who runs the fix.

Responsible disclosure

Found a vulnerability?

Please report it to security@abendly.io. We aim to acknowledge reports within 48 hours and resolve critical issues within 7 days.

Taking this to your security team?

Start where the review is lightest: a health check needs no access at all, and the pilot is read-only on one queue manager.