Ingesting Real-Time Website Uptime and Incident Telemetry into Cognee with UptimeRobot

When a production service goes down, site reliability engineers (SREs), incident commanders, and on-call responders need answers quickly.

They need to know which monitors are failing, whether maintenance explains the disruption, which alert contacts are configured, and how reliable the affected service has been over time.

Questions often include:

• Which monitored endpoints are currently down?
• Is the outage related to a scheduled maintenance window?
• Which alert contacts are configured for the affected monitors?
• What historical uptime information is available for the degraded service?

Monitoring dashboards provide essential operational data, but investigating an incident often means switching between multiple pages and systems.

What if an AI agent could retrieve relevant monitoring metadata from a knowledge graph and use it to help investigate these questions?

That's the idea behind cognee-community-connector-uptimerobot, a community connector designed to bring UptimeRobot monitoring data into Cognee using dlt.

In this article, we'll explore the connector's architecture, ingestion workflow, security considerations, and offline testing strategy.

1. Architecture: Bringing UptimeRobot Data into AI Memory

The UptimeRobot connector integrates the monitoring platform's API with Cognee's data ingestion and memory-processing workflow.

The intended architecture is:

UptimeRobot API v2
        |
        v
UptimeRobot Data-Source Connector
        |
        v
dlt Ingestion Pipeline
        |
        v
Cognee Memory Processing
        |
        v
Knowledge Graph and Search
        |
        v
AI-Assisted Incident Investigation

The connector is designed to ingest four categories of monitoring resources:

• Monitors: Endpoint monitoring configuration and available status information.
• Public status pages: Public-facing service status metadata.
• Alert contacts: Configured notification contacts and channel information.
• Maintenance windows: Scheduled maintenance configuration.

The connector uses UptimeRobot API v2 endpoints, including /getMonitors, /getPSPs, /getAlertContacts, and /getMWindows, according to the described implementation.

The exact fields and resource coverage depend on the API responses and the connector's current implementation.

Key engineering features

1. Deterministic change detection

Repeatedly processing unchanged monitoring records wastes resources and introduces unnecessary updates.

The connector uses canonical SHA-256 fingerprints to identify changes in supported entity records.

The intended behavior is straightforward:

1. Retrieve the upstream resource.
2. Normalize its relevant fields.
3. Calculate a deterministic fingerprint.
4. Compare it with the previously synchronized version.
5. Skip unnecessary updates or process changed records.

For example, a monitor's configuration might remain unchanged for several synchronization cycles. Fingerprinting helps the connector identify records that do not need reprocessing.

A meaningful change in a monitored resource should produce a different fingerprint, provided the changed field is included in the fingerprint calculation.

2. Deletion detection and reconciliation

Monitoring resources are not permanent. A monitor might be removed, an alert contact might be deleted, or a status page might be retired.

The connector is designed to emit tombstones for deleted resources:

{"_deleted": True}

These records communicate deletion to the downstream pipeline.

The complete cleanup process still depends on the configured merge behavior and Cognee's downstream cleanup mechanism. Tombstone generation alone does not guarantee that every stale record disappears from relational, graph, and vector storage.

3. Sensitive-field redaction

Monitoring configurations sometimes contain HTTP Basic Authentication credentials or webhook URLs with sensitive query parameters.

The connector describes a redaction strategy that replaces sensitive values before generating memory documents.

For example, an authenticated monitor might be represented as:

Type: HTTP Monitor
Name: Internal Vault API
Target URL: https://vault.internal.net/health
HTTP Authentication: [Redacted & Protected]

The goal is to retain useful operational context without exposing authentication values.

Webhook URLs require particular care because secrets might appear in their paths or query parameters. A robust implementation should redact sensitive components rather than assume every URL is safe to store.

The redaction policy should be tested across every supported resource type and data path before production use.

2. Installation and Prerequisites

The connector is distributed within the Cognee Community repository.

Prerequisites

• Python 3.10 or a version supported by the current package.
• An UptimeRobot API key with the permissions required for the selected resources.
• Cognee and the connector's dependencies.
• Access to the Cognee Community repository.

Step 1: Clone the repository

git clone https://github.com/topoteretes/cognee-community.git
cd cognee-community

Step 2: Install the connector

Using uv:

uv pip install -e packages/connector/uptimerobot

Run this inside an environment where the required Python dependencies are installed.

Check the connector's package metadata and repository instructions for the supported Python version and dependency setup.

Step 3: Configure the API key

Set your UptimeRobot API key through an environment variable:

export UPTIMEROBOT_API_KEY="your-uptimerobot-api-key"

Use a suitable key for your environment and avoid committing credentials to source control.

The connector's supported key types and required permissions should be confirmed against the current UptimeRobot API and implementation.

3. Quickstart: Ingesting Monitoring Data into Cognee

The following example demonstrates the intended workflow: configure the source, ingest monitoring resources, process the dataset, and ask an operational question.

Verify the connector's current API signatures before running the example.

import asyncio
import os

import cognee

from cognee_community_connector_uptimerobot import (
    uptimerobot,
    UPTIMEROBOT_REMEMBER_KWARGS,
)


async def main():
    api_key = os.environ["UPTIMEROBOT_API_KEY"]

    source = uptimerobot(
        api_key=api_key,
        include=(
            "monitors",
            "public_status_pages",
            "alert_contacts",
            "maintenance_windows",
        ),
        only_down=False,
    )

    dataset_name = "production_infrastructure"

    print("Ingesting UptimeRobot telemetry into Cognee...")

    await cognee.remember(
        source,
        dataset_name=dataset_name,
        **UPTIMEROBOT_REMEMBER_KWARGS,
    )

    print("Processing the knowledge graph...")

    await cognee.cognify(dataset_name=dataset_name)

    query = (
        "List the monitors that are currently down, "
        "their available historical uptime metrics, "
        "and their configured alert contacts."
    )

    print(f"\nQuerying: {query}")

    results = await cognee.search(
        search_text=query,
        dataset_name=dataset_name,
    )

    for index, match in enumerate(results, start=1):
        print(f"\n[{index}] {match}")


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

What does this workflow do?

First, it configures the source. The connector reads the API key from the environment and selects the monitoring resource types to ingest.

Next, it ingests the data. cognee.remember() passes the source through the configured ingestion workflow.

Then, it processes the memory. cognee.cognify() performs the graph-processing step for the selected dataset.

Finally, it runs a query. The search asks for current monitor status, available historical uptime information, and configured alert contacts.

The exact behavior of the search API depends on the installed Cognee version. Confirm the supported arguments and result structure before deploying the script.

Also, ingestion does not guarantee that every requested metric is available. The query can return only information that the API exposes, the connector ingests, and the memory pipeline successfully processes.

4. Entity Types and Representation

The connector organizes monitoring resources into human-readable documents that are intended for embedding and entity extraction.

Entity type	Example document title	Potentially useful context
Monitor	Monitor: Auth Gateway [UP]	Status, target, port, interval, available uptime metrics
Public status page	Status Page: Global Status [Active]	Page URL, custom domain, associated monitors
Alert contact	Alert Contact: DevOps Pager	Contact type, configured status
Maintenance window	Maintenance Window: Weekly DB Backup	Schedule, duration, recurrence configuration

The examples above illustrate a possible representation. The exact field names and title formats depend on the implementation.

This structured context helps an AI agent connect related information across monitoring resources.

For example, an agent might retrieve a monitor and its configured alert contact in the same investigation. Whether the relationship is available in a useful form depends on the records ingested and the graph-processing behavior.

5. Security: Protecting Credentials and Webhook Secrets

Monitoring integrations often handle data that should not be exposed to downstream memory systems.

Consider a monitor configuration containing HTTP authentication:

# Illustrative source payload, not a real credential.
{
    "friendly_name": "Internal Vault API",
    "http_username": "example-user",
    "http_password": "example-password",
}

The intended memory representation excludes the authentication values:

Type: HTTP Monitor
Name: Internal Vault API
HTTP Authentication: [Redacted & Protected]

This approach preserves useful context about the configuration without storing the credentials themselves.

Webhook URLs need similar treatment. A URL might contain a token in its path or query string, so the connector should avoid indexing the raw value when it contains sensitive information.

For production deployments, consider these safeguards:

• Keep API keys in environment variables or a secrets manager.
• Test redaction for every resource type.
• Check generated documents and logs for accidental credential exposure.
• Review URL handling, including query parameters and embedded credentials.
• Restrict access to the resulting Cognee dataset.
• Rotate credentials if exposure is suspected.

Redaction tests increase confidence in the intended behavior. They do not prove that secrets are impossible to expose through every untested code path.

6. Offline Testing and Verification

The project describes a 43-test offline unit and integration test suite that uses a mock client instead of relying on live external API calls.

The reported coverage includes API behavior, data normalization, redaction, state synchronization, and deletion handling.

Run the connector's tests with:

pytest packages/connector/uptimerobot/tests -v

Run the lint checks:

python -m ruff check packages/connector/uptimerobot

Verify formatting:

python -m ruff format --check packages/connector/uptimerobot

The reported result is:

43 tests passed in under 25 seconds

Treat this as the project's reported result until you reproduce it against the relevant commit.

Offline tests help make connector behavior repeatable without network dependencies. They do not replace integration tests against the actual UptimeRobot API or validation of the complete Cognee ingestion and cleanup pipeline.

7. Engineering Lessons

This connector highlights several principles that apply to AI-powered observability integrations.

Synchronize changes, not just snapshots. Monitoring metadata evolves. Deterministic fingerprints help identify changed records and reduce redundant processing.

Treat deletion as a separate workflow. A deleted source record does not automatically disappear from downstream storage. Tombstones and cleanup operations require explicit verification.

Minimize sensitive data. Ingest the information needed for useful retrieval without unnecessarily copying credentials into memory.

Keep metrics grounded in source data. Historical uptime calculations require the appropriate source fields and reporting period. Do not infer a 30-day uptime ratio when the underlying data is unavailable.

Keep live monitoring authoritative. Knowledge graphs provide context, but time-sensitive incident decisions should be validated against the monitoring system.

Together, these principles help make AI-assisted incident investigation more useful and more trustworthy.

8. Project and Repository

Explore the connector and its implementation through the Cognee Community repository.

The connector package is located at:

packages/connector/uptimerobot

Review the source code and tests for the current API support, supported resource types, redaction behavior, and deletion-handling implementation.

Final Thoughts

Connecting UptimeRobot to Cognee creates a path toward AI-assisted investigations grounded in monitoring metadata.

The potential value comes from bringing related information into one searchable memory system: monitor configuration, service status, alert contacts, and maintenance schedules.

The engineering challenge is to keep that information secure, current, and consistent with the source system.

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

Share your thoughts in the comments.