Event Ingestion

What this guide covers

Event ingestion lets you accept alerts from external observability tools. Sentry, AWS CloudWatch, Datadog, Grafana, custom JSON. And turn them into Signalog incidents with routing rules. It’s a Pro/Business feature.

By the end of this guide you’ll have:

1. An event source set up with a unique ingest URL
2. A routing rule that creates incidents from production-fatal Sentry errors
3. A working test ping to verify the pipeline

Step 1: Create an event source

Navigate to Events in the sidebar (admin role required). Click New source.

For each source, set:

• Name. Sentry · production (or whatever describes it)
• Provider: sentry, CloudWatch, Datadog, Grafana, or Generic JSON

Save. Signalog gives you a unique ingest URL:

https://your-domain/events/se_abc123def456...

The token in the URL is the only auth. Keep it secret. Rotate it from the source detail page if it leaks.

Step 2: Wire up the source side

Sentry

1. In Sentry, go to Settings → Integrations → Webhooks
2. Add a new webhook
3. Paste your Signalog ingest URL
4. Select events: event.created (and optionally issue.created)
5. Save

Sentry will POST a JSON payload to your URL on every matching event.

AWS CloudWatch Alarms

CloudWatch sends alarms via SNS. Set it up:

1. Create an SNS topic (or use an existing one)
2. Subscribe an HTTPS endpoint to the topic. Your Signalog ingest URL
3. CloudWatch confirms the subscription via a one-time token (Signalog handles this automatically)
4. Point your alarms at the SNS topic

When an alarm transitions to ALARM (or OK), CloudWatch publishes to the topic and we ingest it.

Datadog

1. In Datadog, go to Integrations → Webhooks
2. Add a webhook
3. Paste your Signalog ingest URL
4. In your monitors, add @webhook-signalog to the notification list

Grafana

1. In Grafana, go to Alerting → Contact points
2. Add a webhook contact point
3. Paste your Signalog ingest URL
4. In your alert rules, route to the webhook contact point

Generic JSON

For anything else, POST a JSON payload to the ingest URL. Signalog stores the raw body and you write JSONPath rules to match against it.

curl -X POST https://your-domain/events/gen_xyz... \
  -H "Content-Type: application/json" \
  -d '{"severity": "fatal", "service": "auth", "message": "token cache miss"}'

Step 3: Configure routing rules

Without rules, every event is logged but no incident is created. Open the source detail page → Routing rules → New rule.

Each rule has:

• Match: field-level conditions (e.g., level=fatal AND environment=production)
• Outcome: what happens when the rule matches:
  • Create incident with a specific severity
  • Notify alert channel (Slack, email, etc.) without creating an incident
  • Both: create an incident AND notify a channel
  • Suppress: explicitly do nothing (useful as a final catch-all)
• Cooldown: minimum gap between successive matches (default 60s) to prevent thrashing

Rules are evaluated in order. First match wins. Drag to reorder.

Example rule chain for Sentry

1. level=fatal                              → Create P1 incident, page on-call
2. level=error AND tag.env=production       → Create P2 incident, notify #ops
3. level=warning                            → Notify #monitoring (no incident)
4. *                                         → Suppress (catch-all)

The catch-all at the end is good practice. It makes the “no rule matched” case explicit instead of silent.

Match syntax

Available operators:

• field=value. Exact match
• field!=value. Not equal
• field~regex. Regex match
• field>value / field<value. Numeric comparison
• AND, OR, parentheses for grouping
• For nested JSON, use dot notation: tag.environment=prod, extra.user.id=42

Step 4: Test with a payload replay

Every event source keeps a recent-events log (last 50). After your first real event arrives, click any row → Replay: signalog re-runs the routing rules and shows which one would fire.

Use this aggressively when debugging. It’s much faster than triggering real alerts in your source.

For Sentry, you can also send a test event from Sentry’s webhook config UI to verify connectivity end-to-end.

Step 5: Watch the events log

The recent-events log shows:

• ✅ matched (which rule)
• ⚠️ unmatched (no rule fired)
• 🔇 suppressed (explicit suppress rule)

If you’re seeing lots of unmatched events, your rules need broadening. If you’re seeing lots of matched-but-no-incident, the rule is firing but the cooldown is in effect. Adjust the window.

Auto-deduplication

Signalog dedups identical events within a configurable window (default 60 seconds per source). Identity is provider-aware:

• Sentry: dedups on the issue fingerprint
• CloudWatch: dedups on the alarm ARN
• Datadog: dedups on the monitor ID
• Generic JSON: dedups on the rule’s matched fields

The incident’s “child events” counter shows how many events folded into it. If you need to break dedup (the same fingerprint represents two genuinely different incidents), do it from the parent incident page.

Plan gating

Event ingestion requires Pro or Business. Free-tier teams see a banner pointing to the upgrade page when they visit the Events sidebar item.

Common gotchas

“Sentry sends events but no incidents are created.” Check the recent-events log. Likely your rules don’t match the actual payload shape. Replay an event to see exactly which rule fires (or doesn’t).

“My rule fires but the incident is duplicated.” The dedup window may be shorter than the source’s burst pattern. Increase it from 60s to 5min and retest.

“I’m being paged for low-severity alerts.” Add a higher-priority level=warning → suppress rule above your catch-all. First match wins.

Next steps

• Understand alert grouping. How Signalog dedups across sources
• Set up the service catalog so events can be routed by service tier
• Configure on-call so paged incidents reach the right person