Skip to main content

Overview

Checks are the core of integrations - they validate compliance against external services and report findings. A check:
  • Fetches data from the service API
  • Analyzes it for compliance issues
  • Reports findings (failures) or passing results (successes)
  • Can map to compliance tasks for auto-completion

Check Structure


CheckContext API Reference

HTTP Methods

Pagination

Auto-pagination (for standardized APIs):
Page number pagination:
Cursor pagination:
Link header pagination:

GraphQL

Logging

Logs appear in:
  • API console during development
  • Trigger.dev dashboard for background jobs
  • Check run logs in database

State Storage

For checks that need to remember data between runs:
Use for: Incremental checks, rate limit tracking, caching

Available Data


Reporting Findings

ctx.fail() - Report an Issue

Required fields:
  • title - Short summary
  • resourceType - Category of resource
  • resourceId - Unique identifier
  • severity - How serious is this?
  • description - Whatโ€™s wrong
  • remediation - How to fix
Optional fields:
  • evidence - Any relevant data (stored as JSON)

ctx.pass() - Report Success

When to use:
  • Check completed successfully
  • Informational results (not just absence of findings)
  • Evidence for auditors
When NOT to use:
  • Just because no issues found (thatโ€™s implied if no fail() calls)
  • For intermediate steps (use ctx.log() instead)

Severity Levels

Default severity can be overridden per finding:

Task Mapping

Auto-complete compliance tasks when checks pass:
Available task templates: See packages/integration-platform/src/task-mappings.ts for the full list. Benefits:
  • Automatic task completion
  • Reduces manual work
  • Keeps tasks in sync with real state
When to use: When the check directly validates what a task requires.

Error Handling

User-Friendly Errors

Bad:
Good:

Common Error Patterns

Permission denied:
Resource not found:
Rate limited:
Service not enabled:

Performance Tips

Batch API Calls

Bad:
Good:

Cache Results


Testing Checks

Manual Testing

  1. Connect the integration with real credentials
  2. Run the check from Cloud Tests or a task
  3. Verify:
    • No errors in API logs
    • Findings appear correctly
    • Remediation steps are clear
    • Evidence contains useful data

Error Case Testing

Test that your check handles:
  • Missing permissions (403 errors)
  • Invalid credentials (401 errors)
  • Resource not found (404 errors)
  • Rate limiting (429 errors)
  • Empty datasets (no resources to check)
  • Malformed responses

Edge Cases

  • User has no resources (empty org)
  • All resources are compliant (no findings)
  • Variables not configured (required variables missing)
  • Dynamic options return empty list

Examples

Simple Check (No External Data)

Data Fetching Check

Iterating Over Resources


Best Practices

Findings vs Passing Results

Only create findings for actual issues:
When to use ctx.pass():
  • Summary results (e.g., โ€œ100 users checked, all have 2FAโ€)
  • Evidence for auditors (e.g., โ€œAccess review completed on 2024-12-08โ€)
  • Donโ€™t use for absence of findings
For cloud tests: Only fail() results are shown. Passing results are filtered out.

Resource Types

Use consistent resource types:

Evidence

Include useful data for auditors:

Remediation Steps

Be specific and actionable:

Performance Considerations

Donโ€™t Over-Fetch

Rate Limits

The platform handles retries automatically, but you can help:

Timeouts

Checks have a 15-minute timeout (Trigger.dev default). For long-running checks:

Examples from Built-in Integrations

GitHub: Secret Scanning

AWS: Security Hub Findings


Checklist for a Good Check

  • Clear, descriptive ID (kebab-case)
  • User-friendly name
  • Helpful description
  • Proper error handling for common cases
  • Meaningful resource types and IDs
  • Specific remediation steps
  • Useful evidence (not too much, not too little)
  • Appropriate severity levels
  • Task mapping (if applicable)
  • Variables for user configuration (if needed)
  • Tested with real API credentials
  • Handles edge cases (empty data, missing resources)

Summary

Checks are the heart of integrations. Write them to be:
  • Focused: One check = one compliance validation
  • ๐Ÿง‘โ€๐Ÿ’ป User-friendly: Clear errors, actionable remediation
  • ๐Ÿ”’ Secure: Handle credentials properly, never log secrets
  • โšก Efficient: Batch requests, handle pagination
  • ๐Ÿงช Tested: Verify with real credentials and edge cases
Great checks = happy users = successful integration!