Proactive Incident Intelligence: Syncing Checkly Monitoring into Cognee Memory with dlt

Modern applications cannot afford to wait for users to report outages. Engineering teams use synthetic monitoring platforms like Checkly to test REST APIs, execute automated Playwright browser flows, and detect failures before they affect more users.

But detecting an incident is only half the problem. Engineers also need context to understand what is failing, which alerts are configured, and whether maintenance windows explain the behavior.

During an incident, an engineer or AI agent might need to answer questions such as:

• Which synthetic API checks or checkout flows are failing?
• Which alert channels notify the team about API degradation?
• Are the affected endpoints covered by a scheduled maintenance window?

Answering these questions often requires information from multiple resources.

In this article, we explore cognee-community-connector-checkly, a Checkly data-source connector developed for the Mergetober 2026 hackathon. It is designed to synchronize synthetic monitoring metadata into Cognee using dlt.

We'll examine its architecture, secret-safe ingestion strategy, health-status synchronization, deletion handling, and offline testing approach.

1. Architecture: Bringing Synthetic Monitoring into AI Memory

The connector resides in the Cognee Community monorepo, under:

packages/connector/checkly

Its architecture connects three components:

• Checkly: Supplies synthetic monitoring data and configuration.
• dlt: Handles structured data ingestion and incremental synchronization.
• Cognee: Processes ingested information for knowledge-graph and semantic retrieval.

The intended data flow is:

Checkly API
    |
    v
Checkly Data-Source Connector
    |
    v
dlt Ingestion Pipeline
    |
    v
Cognee Memory Processing
    |
    v
AI-Powered Incident Investigation

The goal is to give AI agents useful operational context without treating monitoring data as static documentation.

Core design principles

1. Secret-safe metadata ingestion

Synthetic checks often use authenticated requests, API tokens, cookies, and basic authentication. Check groups might also contain environment variables with sensitive values.

Indexing these values in a knowledge graph or vector store introduces unnecessary risk.

The connector follows a key-only redaction strategy for supported headers and environment variables. Instead of storing a sensitive header value, the intended representation retains its name:

Headers (keys only): Authorization

Likewise, environment variables are represented by their names:

Environment Variables (keys only):
STRIPE_SECRET_KEY, API_BASE_URL

This preserves structural information that helps explain a check's configuration without deliberately copying the associated values into memory.

The implementation must apply this policy consistently across every ingestion path. Redaction tests help verify the behavior, but they do not replace a broader security review.

2. Health-status propagation

Check definitions describe what should be monitored. Health-status data helps explain what is happening now.

The connector is designed to retrieve check-status information through the /v1/check-statuses endpoint and associate the results with relevant monitoring records.

The intended benefit is to make health information available alongside check configuration. An AI agent could then investigate questions such as:

Which synthetic API checks are failing or degraded, and which alert channels are configured to notify the team?

The usefulness of these answers depends on the connector's status mapping, the API response, and the freshness of the latest successful synchronization.

3. Merge-based synchronization and deletion handling

Monitoring resources change over time. Checks are updated, groups are removed, and temporary configurations become obsolete.

The connector uses merge-based ingestion:

write_disposition="merge"

It also uses a _deleted tombstone mechanism with hard-delete semantics to represent upstream deletions.

The intended workflow is:

1. Detect that a resource no longer exists upstream.
2. Emit a tombstone for the deleted resource.
3. Pass the deletion signal into downstream cleanup.
4. Remove stale records from the relevant storage layers.

Cognee's cleanup process must execute successfully for the deletion to propagate through relational, graph, and vector storage. Emitting a tombstone alone does not guarantee complete cleanup.

2. Quickstart: Integrating Checkly with Cognee

Step 1: Install the dependencies

Install the connector and its main dependency:

pip install cognee cognee-community-connector-checkly

Use a virtual environment and verify the supported package versions in the repository before running the integration.

Step 2: Configure your Checkly API key

Retrieve your API key from Checkly and configure it through an environment variable.

For Linux or macOS:

export CHECKLY_API_KEY="your-checkly-api-key"

For an account-specific configuration, set the optional account ID:

export CHECKLY_ACCOUNT_ID="your-checkly-account-id"

Keep credentials out of source control. For production deployments, use your platform's secrets manager or another approved credential-management mechanism.

Step 3: Synchronize monitoring metadata

The following example illustrates the intended integration. Verify the current connector and Cognee API signatures against the repository before running it.

import asyncio
import os

import cognee
from cognee_community_connector_checkly import checkly_source


async def main():
    api_key = os.environ["CHECKLY_API_KEY"]
    account_id = os.environ.get("CHECKLY_ACCOUNT_ID")

    source = checkly_source(
        api_key=api_key,
        account_id=account_id,
        resource_name="checkly_prod",
        include=(
            "checks",
            "check_groups",
            "alert_channels",
            "maintenance_windows",
        ),
    )

    print("--- Ingesting Checkly metadata ---")

    await cognee.remember(
        source,
        dataset_name="synthetic_monitoring_memory",
        primary_key="id",
        write_disposition="merge",
        max_rows_per_table=0,
    )

    print("Sync stats:", source.cognee_sync_stats)

    print("\n--- Querying monitoring memory ---")

    result = await cognee.search(
        query_text=(
            "Which synthetic API checks are failing or degraded, "
            "and which alert channels notify on failure?"
        ),
        query_type=cognee.SearchType.GRAPH_COMPLETION,
        datasets=["synthetic_monitoring_memory"],
    )

    print("Monitoring insights:\n", result)


if __name__ == "__main__":
    asyncio.run(main())

This example demonstrates three main operations:

1. Configure the Checkly connector using environment variables.
2. Ingest checks, groups, alert channels, and maintenance-window metadata.
3. Query the resulting Cognee dataset using natural language.

The exact resources available depend on the connector implementation and the installed version. Confirm that each resource type is supported before using the example in production.

Step 4: Ask incident-related questions

After ingestion and memory processing complete successfully, try queries such as:

• Which synthetic API checks are failing?
• Which alert channels are configured for the affected checks?
• Which check groups contain the failing checks?
• Which maintenance windows overlap with the incident?
• What monitoring configuration is associated with the affected endpoint?

These questions illustrate how structured monitoring metadata might support AI-assisted incident investigation.

One important distinction: synchronizing monitoring metadata does not automatically create a real-time incident response system. The freshness of the results depends on synchronization frequency, and critical incident decisions should be checked against authoritative monitoring data.

3. Comprehensive Offline Test Suite

Reliable ingestion requires more than successful API responses. A connector must handle network failures, rate limits, changing health states, sensitive values, and deleted resources.

The project reports a 45-test offline suite covering the following areas.

API client behavior

• Retry handling for HTTP 502 responses.
• Connection-drop retries.
• Rate-limit header parsing.
• Account scoping through X-Checkly-Account.
• API token redaction.

Secret-redaction verification

Tests use sensitive-looking values in fixtures to verify that credentials do not appear in emitted document text.

Examples include:

Authorization: Bearer secret
STRIPE_SECRET_KEY

The important distinction is between retaining a configuration key and retaining its sensitive value. The connector should preserve only the information required for its intended use.

Health-transition detection

A synthetic check might report HEALTHY during one sync and FAILING during the next.

The connector's fingerprinting strategy is designed to detect meaningful changes and re-emit updated records. This helps prevent AI memory from remaining stuck on an earlier state.

Forget-on-delete verification

When a Checkly resource is deleted, the connector should detect the removal and emit a _deleted=True tombstone.

The downstream pipeline must then process that tombstone and remove the corresponding stale data.

SQLite-backed dlt pipeline

The suite also describes an SQLite-backed pipeline that exercises merge behavior and hard-deletion handling across successive runs.

Run the tests with:

pytest packages/connector/checkly/tests -v

The reported result is:

45 passed in 22.70s

This is the reported test result, not an independently verified result. Reproduce it against the relevant commit before presenting it as your own verified run.

Offline tests provide repeatable coverage of the behaviors they exercise. They do not replace integration testing against Checkly or validation of the complete downstream cleanup pipeline.

4. Engineering Lessons

This connector illustrates several principles that apply to AI integrations across monitoring and infrastructure systems.

Minimize sensitive data. Retain the metadata needed for retrieval without unnecessarily copying credentials into documents or indexes.

Track changing operational states. Monitoring data evolves. Incremental synchronization should recognize meaningful changes rather than treating every record as immutable.

Design deletion handling explicitly. Removing a resource from its source does not automatically remove every downstream representation. Tombstones and cleanup operations need separate verification.

Make synchronization observable. Fingerprints and sync statistics help engineers understand which records changed and which were skipped.

Keep operational truth authoritative. AI memory helps connect related information, but live incident status should be verified against the monitoring system when decisions depend on current conditions.

These principles apply to other integrations involving application logs, distributed traces, deployment systems, infrastructure inventories, and incident-management platforms.

5. Project Links

The connector was developed as part of the Mergetober 2026 hackathon.

• Pull request: Cognee Community PR #447
• Feature issue: Cognee Issue #6124
• Repository: Cognee Community Monorepo
• Cognee: GitHub repository

Visit the pull request and repository for the implementation details, supported configuration, and current test results.

Final Thoughts

Connecting Checkly synthetic monitoring to Cognee offers a way to give AI agents more context about application reliability, monitoring configuration, and incident investigation.

The difficult engineering work lies in maintaining that context safely and accurately: protecting credentials, tracking health changes, synchronizing updates, and removing deleted resources.

If you were building an AI incident investigation agent, which data source would you integrate next: application logs, distributed traces, deployment history, or incident-management data?

Share your thoughts in the comments.