Why teams send Graylog alerts to a ticketing or SOAR tool with webhooks
Teams send Graylog alerts to a ticketing or SOAR tool so that each alert becomes a tracked case or starts a defined playbook, instead of being read once in a chat channel and lost. Graylog raises alerts from event definitions, and the notification step decides where those alerts go. HTTP and Custom HTTP notifications send an HTTP request to an endpoint you choose, which is how an alert can open a ticket in a case management tool such as TheHive or start a workflow in an automation platform such as Shuffle. These notifications are part of Graylog Enterprise or Graylog Security, not Graylog Open. Graylog Open is licensed under SSPL-1.0, and the Graylog Open product page lists PagerDuty, Slack and email as its notification targets, so do not plan a webhook design on the assumption that the free edition includes it.
The license decision comes before the design work. Confirm on the Graylog pricing page which edition includes HTTP and Custom HTTP notifications, and confirm the minimum processing commitment that applies to that edition. Then ask the target tool's vendor whether its receiving endpoint accepts the payload shape you intend to send and whether it needs an API key or a token in a header. Both answers affect who builds the integration, how secrets are stored and whether the ticket flow can be tested end to end before go-live.
The webhook is only the first hop. Once an alert becomes a case or playbook run, your team must decide which event fields travel with it, how the receiving tool matches a repeated alert to an open ticket, and who owns the endpoint when it changes. Those decisions shape payload design, authentication and duplicate handling, which the sections below address. Treat them as design inputs for the integration, not as settings to adjust after the first ticket arrives.
Which notification and target fits your workflow
This table compares the Graylog notification types and downstream targets for sending alerts to ticketing and SOAR tools. Read each row against your Graylog edition and the receiver you run, because the choice often depends on whether the receiver can accept a generic JSON body and whether you need a case or a playbook run.
| Option | Best fit | What the receiver must accept | Confirm in your Graylog version |
|---|---|---|---|
| HTTP notification | Simple, fixed-format POST to one endpoint | A single known JSON shape with an endpoint that accepts POST requests | Notification type is available in your edition and the fields it sends match your receiver |
| Custom HTTP notification | Custom body, headers and authentication for a specific tool | Your template-defined payload, a header or token scheme, and a status code you can handle | Template variables, header support and how failed deliveries are reported in your release |
| Direct ticket integration | Teams that want tickets without a middle layer | The ticketing system's own API or inbound email format | Whether a native integration exists for your ticketing product and its edition |
| SOAR-side ingestion | Teams that want enrichment and routing before a ticket exists | A webhook or API listener on the SOAR platform that maps Graylog fields to its own model | Which trigger types your SOAR version offers and how it authenticates inbound requests |
| TheHive case creation | Analysts who work cases, observables and tasks in TheHive | Alert or case payloads mapped to TheHive fields, with a valid TheHive license | TheHive edition and license status, since TheHive 5 Community is limited to 2 users and read-only mode applies without a valid license |
| Shuffle workflow trigger | Teams that want automated enrichment, containment or routing playbooks | A webhook trigger URL in a workflow, with apps configured and credentials stored | Shuffle edition limits, since app runs are the licensing metric and skipped actions are not counted |
Designing the payload Graylog sends
The most important decision in a Graylog webhook is which event data leaves the environment at all. Send only the fields the receiver needs to open or update a ticket or start a playbook, which typically means the event definition title, the priority, the source system, the affected user or host, the event timestamp, and a short set of backlog messages that show what triggered the alert. Keep the full raw log text, internal stream names and anything containing personal data inside Graylog unless the receiving team has a documented need for it. Confirm the exact event and backlog fields available in your Graylog version in the Graylog documentation before you build the template, because the names differ between event types and releases, and do not assume that every field is present on every event.
Graylog lets you write a custom body template for an HTTP or Custom HTTP notification, so the payload can be shaped to the receiver's schema instead of sending Graylog's default structure. Map each value deliberately: the ticket title should come from the event definition title, the severity should be translated into the receiver's own scale, and the description should carry a link back to the event in Graylog. Test the template against a sample event and inspect the request on the receiver side. If the receiver is TheHive or Shuffle, check each mapped field against its current API documentation, since a field that is optional in one version can be required in another.
The receiver can only correlate repeated notifications if the identifier stays stable. Pick a key that does not change between firings, such as the event definition identifier combined with the affected host or user, and place it in a field the receiver uses as its external reference. Without this, every repeated alert becomes a new ticket or a new playbook run, which is the usual cause of duplicates. Decide in advance how the receiver handles an update to an existing case, and document which Graylog field supplies the key. Agree the scheme with the team that owns the ticketing or SOAR tool before the first alert fires in production.
Avoiding duplicate tickets when alerts repeat
A webhook that opens a ticket for every notification will open many tickets for one incident. Duplicates come from the alert logic in Graylog, from the delivery path and from the receiving tool, so each source needs its own control.
Repeated aggregation windows re-fire
A Filter and Aggregation event definition evaluates its lookback window on every interval. If a spike stays inside the window, the same condition can match again and send another webhook for the same underlying events. Check the lookback and interval together, and confirm whether your Graylog edition lets the notification fire once per event group rather than once per evaluation. Test the definition against a known burst and count the notifications it sends.
Backlog replays after recovery
When a Graylog node or the receiving tool is down, messages queue in the journal and are processed later. Historical searches and event definitions can then evaluate old data and send notifications for events that already have tickets. Compare event timestamps with ticket creation times in the playbook, and skip or mark events older than the last successful run.
Retries after timeouts
If Graylog does not receive a response before its HTTP timeout, it may treat the delivery as failed and send it again while the receiver has already created the ticket. The first request then succeeds and the retry creates a second record. Ask the receiver to return quickly, set the timeout on the Graylog side deliberately, and make the playbook idempotent so a repeated call updates the existing case.
Overlapping event definitions
Two event definitions that match the same log events, such as a broad failed-login rule and a per-host brute-force rule, will each send a notification. The result is two tickets for one activity. Map each source event to one owning definition, list which definitions share a stream, and add a rule identifier to the payload so the receiver can group them.
Stable external reference
Put a deterministic key in the payload, built from the event definition ID, the grouping fields such as user or host, and the time bucket. Your SOAR playbook or ticketing tool searches for an open case with that key before creating one. Use the same key in every notification for the same incident, and document how it is built so responders can trace it.
Update-instead-of-create logic
Receiver-side deduplication only works if the playbook checks for an existing case and appends to it. Add a branch that finds the open case by the external reference, adds the new event as a comment or field update, and creates a new case only when none exists or the prior one is closed. Test both branches with a repeated payload before going live.
Setting up a webhook from Graylog to TheHive or Shuffle
This sequence connects one Graylog event definition to one receiver in TheHive or Shuffle, so each alert opens a single case or workflow run. It finishes with a verified test on a non-production stream and a controlled rollout to production alerts.
Confirm the Graylog edition and version
The Graylog platform owner confirms that the cluster runs a version covered by current documentation, which is 7.2 at the time of writing, and that the license includes HTTP and Custom HTTP notifications, which need Graylog Enterprise. The Graylog pricing page lists Enterprise from 15,000 US dollars per year, so confirm the tier with your Graylog account contact before building. Check the version in the web interface and record the license tier. Done when both match your plan and the notification types appear in the event notification options.
Create and test the receiving endpoint
The security engineer creates the receiving side in TheHive or Shuffle. In TheHive, confirm the instance holds a valid license first, because the on-premises trial switches to read-only after 14 days and Community users need a license from the StrangeBee portal. In Shuffle, create a workflow with a webhook trigger and note its URL. Send one hand-written sample payload with the fields you expect from Graylog. Done when the request is logged by the receiver and the sample fields are visible to the workflow or case template, with no case or run created by accident.
Store credentials in the notification configuration
The engineer creates a dedicated service account or API key for Graylog in the receiver, with permissions limited to creating alerts or cases. The key goes into the Graylog notification configuration, not into event definition titles, descriptions or payload templates that many administrators can read. On a Shuffle receiver, confirm that SHUFFLE_ENCRYPTION_MODIFIER is set and backed up, because the docs warn that losing or changing it breaks saved app authentications. Done when a request with the correct key is accepted and a request with a wrong key is rejected.
Create the HTTP notification with a limited payload
The administrator creates an HTTP or Custom HTTP notification in Graylog, sets the receiver URL, method and headers, and writes a body template that includes only the event fields the receiver needs, such as the event definition title, priority, source, user, host and a stable event identifier. Avoid placing full raw messages in the body unless the case workflow needs them. Use the notification's test option if your Graylog version offers one, and confirm field names in the receiver log. Done when the test body arrives with every field populated and no unexpected sensitive values.
Attach the notification to a test event definition
The engineer creates an event definition on a test stream that holds sample or lab logs, with a simple condition that the team can trigger on purpose. Attach the new notification, set a clear custom title and a priority, and make sure the event carries a field the receiver can use to recognize the same event later. Keep the definition out of production streams until the test passes. Done when the event definition lists the notification and the stream contains only test data.
Fire a controlled test alert
The engineer sends a known test log that meets the condition, using an input the team already controls. Graylog should evaluate the event definition and call the notification once. Record the time, the event identifier and the message used so the result can be compared with the receiver. Done when Graylog shows the event as triggered and the receiver logs one inbound request with the expected body and a valid credential.
Verify exactly one case or workflow run
The security engineer checks TheHive for new cases or Shuffle for new workflow executions created by the test. There should be exactly one per triggered event. Repeat the test with the same condition while the event definition is still active, and confirm whether the receiver deduplicates on the event identifier or whether a second case appears. Confirm your Graylog version's behavior for retries after a failed request with the vendor documentation before relying on it. Done when each test event maps to one case or run. If duplicates appear, fix the receiver logic before continuing.
Roll out to production event definitions
The Graylog and SOC teams move the tested notification onto production event definitions during an agreed change window, one definition at a time. They record the owner, the receiver URL without credentials, the fields sent and the disable step for each definition. They watch the first production alerts and compare each case or run with its Graylog event. Done when every production alert maps to one case or run, and the runbook lists how to disable the notification if the receiver fails.
Authentication options for the receiving endpoint
TheHive 5 accepts API requests from integrations, so a Graylog notification that creates alerts or cases needs a credential the TheHive instance will accept. Confirm in the TheHive 5 documentation whether your target should use a personal API key or a dedicated service account, and which request header carries it. Do not assume the header name from another product. Because a TheHive on-premises install needs a valid license to stay writable, check the licensing state before you test the integration, since a read-only instance will reject new alerts.
- Dedicated identity: Create a service account or integration user for Graylog rather than reusing an analyst's personal key, so the audit trail shows which system opened each alert.
- Minimal profile: Give that account only the permissions needed to create alerts and cases in the target organization, and confirm the role names in the current documentation.
- Storage: Place the key in the Graylog notification configuration only if your Graylog edition and access controls keep it protected, and restrict who can view or edit notifications.
- Rotation: Plan a rotation date, update the key in Graylog and TheHive together, and test with a non-production alert before the old key is removed.
- Scope check: Confirm whether the key is limited to one organization, which matters for multi-tenant setups.
Before go-live, ask the TheHive administrator to confirm the key type, header name and role assignment from the version you run.
In Shuffle, a workflow usually starts from a webhook trigger, which gives Graylog a URL to call. Confirm in the Shuffle documentation whether that trigger URL is enough on its own, or whether your version also requires a key or secret in the request. The trigger URL identifies the workflow, so anyone who holds it can start the playbook, which makes it a sensitive value even when no separate key is used. Treat it like a credential from the start.
- Treat the URL as a secret: Store the full trigger URL in a protected location, and avoid pasting it into tickets, chat or shared runbooks.
- Separate workflows: Use one webhook trigger per purpose, such as alert intake or enrichment, so that revoking one does not disrupt the others.
- Secret storage: Shuffle encrypts saved app credentials in its database with a secret named SHUFFLE_ENCRYPTION_MODIFIER. Keep that value in your secret manager, back it up securely, and never change it casually, because the docs warn that changing or losing it breaks saved app authentications.
- Network controls: Limit which hosts can reach the trigger endpoint, and confirm how your deployment model handles inbound ports.
- Rotation: Replace the trigger by creating a new workflow trigger or key as your version supports, then update Graylog and retire the old one.
Before you build, confirm with the Shuffle documentation for your release whether the trigger requires a key, and which header or parameter carries it.
Whichever receiver you use, the same lifecycle questions apply: who holds the credential, where it lives, how it changes and how far its access reaches. Graylog notifications are configuration objects that administrators can read and edit, so the credential is only as protected as the access controls around Graylog itself. Agree on these rules with your security team before any alert is sent, and record them in the runbook for the integration.
- Ownership: Name one owner for each credential and one for each receiving workflow or organization.
- Least privilege: Scope each credential to the single purpose it serves, such as creating alerts, and avoid administrator accounts.
- Rotation cadence: Set a rotation schedule that matches your policy, and rehearse the change in a test environment first.
- Revocation: Know how to disable a credential quickly if a Graylog node or administrator account is compromised.
- Evidence: Keep records of who created, changed and revoked each credential, so auditors can trace the integration.
Ask your Graylog and SOAR administrators to confirm how each receiver handles revocation and whether a rotation causes downtime for queued alerts.
Security controls for alert data in transit and at rest
A webhook sends event data out of Graylog and into a ticketing or SOAR system, so the same controls that protect a log pipeline apply here. The cards below cover the transport, the credentials, the data that leaves Graylog, the network path and the people who can change the notification.
TLS to the receiver
Send every webhook to an HTTPS endpoint with a certificate that Graylog trusts. Confirm whether your Graylog build verifies the receiver certificate against your internal certificate authority, and whether it can be pointed at a private CA bundle. Plain HTTP sends alert titles, usernames and host names in cleartext across any network segment the packet crosses.
Least-privilege service accounts
Create a dedicated user or API token on the ticketing or SOAR side that can only create and update tickets in one project or workflow. Avoid reusing an administrator's personal token. Ask the receiver's vendor which permissions a token needs to open, comment on and close a case, and grant only those.
Restricting which event fields leave Graylog
Decide the payload fields before the webhook goes live. Events can carry message text, user names, source addresses and custom fields that may hold personal data or secrets. Send only the fields the responder needs to triage, and review the message field for passwords, tokens or session identifiers that a log source may have written.
Protecting the webhook URL and secrets
Many receivers authenticate a request through a token placed in the URL or a header, so the full URL is a credential. Store it in Graylog's notification configuration only, restrict who can read it, and rotate it when staff leave. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that secret breaks every saved app authentication, so back it up in a controlled vault before you rely on it.
Network path and firewall rules
Limit outbound traffic from the Graylog server nodes to the named receiver address and port only. Where the SOAR side is hosted by a vendor, confirm which source addresses the vendor calls from. Shuffle's hybrid model runs a local Orborus that needs no inbound firewall ports, which can reduce exposure when the SOAR backend sits in another network zone.
Auditing who can edit notifications
Changing a notification's URL, body template or attached event definition changes where sensitive alert data goes. Limit notification administration to a small role, and review changes on a schedule. Confirm with your Graylog edition whether notification changes are recorded in an audit trail, and where that trail is kept.
Operating webhook alerting after go-live
The first thing to plan after go-live is how you will know a webhook failed. Graylog sends the HTTP or Custom HTTP notification from the event, and nothing in the ticket or playbook path tells you when a delivery did not arrive. Confirm with your Graylog edition and version how notification errors appear in the server logs, then set an alert or log check on those errors. Decide who receives them, and test the path by pointing a test event definition at a deliberately unreachable receiver. Also decide what happens during a receiver outage: whether Graylog retries, whether the event remains visible in the Events view for manual replay, and whether responders are told to check the All Events stream for alerts that never became tickets.
Receiver availability is its own design decision. For Shuffle, follow its documented high availability recommendations: an OpenSearch cluster for its database, more than one Orborus node so workflows keep running if one fails, and the backend and frontend scaled across servers, with NFS for shared files when several backends run. For TheHive, size storage against the TheHive 5 system requirements, which describe the JVM services (TheHive, Cassandra and Elasticsearch) and recommend 100 GB of storage for most use cases, then check that figure against your own alert volume. Ask your team to confirm how the receiver behaves during a restart so you know whether alerts are queued, dropped or re-sent when it returns.
Changes to Graylog, the receiver or the payload need their own test cycle. After each Graylog upgrade, resend a known test event to every webhook and confirm that the field names, the template values and the authentication headers still match what the playbook expects. Treat the payload as an interface: add new fields rather than renaming existing ones, and version the playbook when a breaking change is unavoidable. Keep a runbook that lists each notification, the Graylog event definition behind it, the receiver it calls, the playbook or ticket queue it feeds, and the named owner for each. Review that list whenever someone leaves the team, because an unowned webhook is the one most likely to fail silently.
Limits to confirm before you commit to a webhook design
Webhook alerting from Graylog touches three products with their own license and version rules: the Graylog notification, the ticketing or SOAR tool that receives the call, and the open-source components behind it. Confirm each limit below before you choose a design, because a limit found after build can force a rework of payloads, authentication and hosting.
Graylog notification edition requirement
HTTP and Custom HTTP notifications are Graylog Enterprise features, so an Open deployment cannot send them as configured. Confirm the edition, the notification type and the Graylog version you run before you design the payload, since notification behavior can change between releases. The current Graylog documentation covers version 7.2, and your target version should be the one you test against. Ask your Graylog partner or licensing contact to confirm the entitlement in writing before the build starts.
TheHive 5 license model
TheHive 5 on-premises offers a Community plan limited to 2 users, with Gold and Platinum plans priced per user. A new install starts with a 14-day Platinum trial, after which TheHive switches to read-only mode until a valid license is applied. Since version 5.3, Community users must request a Community license from the StrangeBee portal. Model your analyst count and confirm the plan and license steps before you rely on TheHive as the ticket destination.
Legacy TheHive versions are unmaintained
TheHive 3 and TheHive 4 have not been maintained, distributed or publicly accessible since 2023, and their repositories are archived. The last TheHive 4 release, 4.1.24, dates from September 13, 2022. Any existing webhook integration built against those versions carries no vendor fixes, so plan a move to TheHive 5 as part of the design rather than as a later task. Inventory the TheHive version each integration targets before you reuse payload formats from older guides.
Shuffle app run metric and edition limits
Shuffle licenses on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions do not count, and users, apps and workflows are unlimited. Limits between the open-source and enterprise editions are enforced since v2.1.1, so a workflow that works in testing can hit a cap at volume. Estimate executions per alert, including retries and enrichment calls, and confirm the edition limits with Shuffle before you choose a hosted or self-hosted runtime.
License differences across components
The Graylog Open server is licensed under SSPL-1.0, which is not an OSI-approved license, while Shuffle's backend and TheHive's archived 4.x code and Cortex use AGPL-3.0. Shuffle's workflows and apps are MIT licensed. Mixing these components changes your obligations if you modify code, offer the software as a network service or redistribute it. Have legal review each component's license before you integrate, and confirm which parts you intend to change.
Questions teams ask before sending Graylog alerts to a ticketing or SOAR tool
What does it cost to send Graylog alerts to a ticketing or SOAR tool?
The cost comes from four components: the Graylog edition, the receiver's licensing, the number of integrations, and the testing effort. HTTP and Custom HTTP notifications are part of the Enterprise and Security tiers rather than Graylog Open, so the first cost question is which edition the team already licenses or plans to license. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, according to the Graylog pricing page, each with a minimum of 10 GB per day or 100 Graylog Compute Units. The receiver adds its own cost: TheHive 5 on-premises Community is free for 2 users, while Gold and Platinum are priced per user, and Shuffle licenses on app runs. Ask for a quote that separates one-time build work from recurring support, upgrades and testing.
How long does a basic Graylog webhook to a ticketing tool take to build?
A single webhook that opens one ticket with a fixed set of fields is the smallest version of this work, and its duration depends on the payload, the receiver's API and how many event definitions feed it. Payload design, authentication to the receiver, and a test pass against a non-production instance are the main variables. Each additional event type, custom field mapping or playbook trigger adds design and test effort. Because no duration has been established for this scope, ask the partner to state the expected effort and the receiver version in the written scope before work starts.
What does our internal team need to provide for a webhook integration?
Three inputs are needed before build starts. The first is access to the receiver, meaning an API endpoint, a service account or API key with the right permissions, and a non-production instance for testing. The second is data ownership: someone must confirm which event fields may leave Graylog, since alert payloads often carry user names, host names and source addresses. The third is playbook logic, including the priority levels that open a ticket, which alerts should close or update an existing ticket, and who owns the response steps. Without these decisions written down, the webhook will send data that nobody has agreed to share.
Can our own engineers build a Graylog to ticketing integration without a partner?
Yes, a single webhook to one receiver is a reasonable task for an engineer who knows the Graylog event definitions and the receiver's REST API. The harder parts are deduplication, where one incident must not create many tickets, and playbook design, where alert logic, enrichment and escalation interact. Those tasks need a clear model of event keys, update-or-create logic and failure handling, and they are easy to get wrong in ways that only show up during a real incident. Teams often build the first webhook internally and bring in a partner for the deduplication rules, playbook structure and testing plan.
Should TheHive or Shuffle be the receiver for Graylog alerts?
The choice depends on whether the team needs case management or automation as the main job. TheHive is a case management platform, and TheHive 5 uses Cortex for analysis and response; note that TheHive 3 and 4 are no longer maintained, so any new build should target TheHive 5. Shuffle is a SOAR platform for running playbooks against many tools, and its server runs an OpenSearch database with Orborus runtimes that need careful sizing for high availability. Teams that already run a case tool usually send Graylog alerts into it first, then use an automation layer for enrichment. Confirm the receiver version, its license terms and its hosting model before you choose.
What security checks apply to webhook credentials and alert data?
Webhook credentials need the same care as any service account. Store the receiver API key or token in Graylog's secret handling rather than in event definition text, limit the key's permissions to creating and updating tickets, and rotate it on a schedule your security team sets. For Shuffle, saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that secret breaks every saved authentication, so it must be backed up with the rest of the configuration. Limit the fields in each payload to what responders need, and confirm that the receiver's transport uses TLS to an endpoint you control.
How do we request a fixed-scope quote for this integration?
Send a written description of the receiver and version, the Graylog edition you run or plan to license, the number of event definitions to connect, the payload fields each receiver needs, the authentication method, and whether deduplication or playbook logic is in scope. DeployOpen works from a written scope, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask for the quote to list the design, build, test and handover steps separately, and to state which items are one-time and which are retainer-based support. DeployOpen does not publish a price list, so the written scope determines the quote.
What a fixed-scope webhook integration includes
A fixed-scope webhook integration starts with requirements on the alert sources: which Graylog event definitions will send to the ticketing or SOAR tool, which streams and priorities they belong to, and which event fields must leave Graylog. The written scope should list each alert, the receiving endpoint, and the owner who approves changes to either side. Requirements also cover the Graylog edition, since HTTP and Custom HTTP notifications are part of the Enterprise feature set, so the scope should confirm the license before any build time is committed.
The core deliverables are a payload specification, a receiver configuration and a deduplication design. The payload specification defines each field name, its source in the event, and how the receiver maps it to a ticket or playbook input, including the event identifier used as the deduplication key. The receiver configuration covers the endpoint, authentication method, secret storage and any mapping workflow on the SOAR side. The deduplication design explains how repeated notifications for one ongoing condition update an existing record instead of opening a new one. Ask for each of these to be written as a separate, reviewable artifact.
Test evidence and a runbook close the engagement. Test evidence should show each alert firing with sample data, the ticket or playbook result, the duplicate-suppression behavior under repeated triggers, and the failure path when the receiver is unavailable. The runbook records how to rotate credentials, change a payload field, disable a notification, and investigate missed or duplicate tickets. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list. A quote follows from that written scope, so ask for the deliverables above to be listed individually and any open items on the receiving tool's side to be named as client responsibilities.
How DeployOpen scopes and delivers Graylog webhook integrations
DeployOpen plans, builds, tests and documents Graylog webhook integrations inside your own infrastructure, so alerts reach your ticketing or SOAR tool with the fields your responders need. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- We confirm which Graylog edition and license your alerting needs, since HTTP and Custom HTTP notifications depend on it.
- We map each alert source, target tool, payload field and deduplication key into a written scope.
- We agree the authentication method, secret storage location and who owns the receiving tool's API credentials.
How we build
- We build and version the event definitions, notification payloads and receiving workflows in your environment.
- We test each alert path with controlled events, including repeated firings, to confirm one event produces one ticket.
- We confirm the event fields that leave Graylog are limited to what the target tool needs, and nothing more.
How we hand over
- We deliver written documentation of each alert, payload schema, field mapping, credential location and rotation steps.
- We walk your operations and security teams through failure cases, such as an unreachable endpoint or a rejected token.
- We provide a handover checklist so your team can add or change alerts without guessing at the existing design.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover re-testing after Graylog or receiving-tool upgrades, which can change payload behavior.
- Ask us to confirm the support scope, response expectations and upgrade handling in the written quote.
