Nijam fits where your team already works.

Your suite reports into Nijam, and Nijam reports back out: into Slack, onto the pull request, and into whatever AI agent you code with. Nobody has to open a dashboard to find out the build went red.

Slack, GitHub, and GitLab

Connect once for the whole organization, then tune it per project. Every integration is optional and every one can be muted for a project that shouldn't report.

Slack

Every verdict in the channel your team already watches.

Connect a workspace once, pick a default channel, and Nijam posts a summary of each run: passing, flaky, or failing, with the counts, the branch, the commit, the author, and a link straight into the run.

  • Choose when it posts: every run, only failures, failures or flaky, or only regressions (the first failure after a passing run).
  • Compact for status and counts, or full to list each failed and flaky test with its error.
  • Block Kit or Classic layout, previewed live while you're configuring it.
  • Per-project overrides: a different channel, a branch filter, or mute Slack entirely for one project.

GitHub

The result on the pull request, before anyone asks.

Install the GitHub App for your organization and every run on a pull request posts a status check plus a results comment. The comment updates in place on each re-run instead of stacking up.

  • One status check per PR, so a red suite blocks the merge.
  • A single results comment with the pass, fail, and flaky counts, rewritten on each run.
  • Branch filters per project, so only the branches you care about report.

GitLab

Commit statuses and merge-request notes.

The same workflow for GitLab: connect once at the organization level, and runs on a merge request post a commit status and a results note.

  • A commit status on the pipeline so the MR reflects the suite.
  • A results note on the merge request with the run breakdown.
  • The same per-project branch filters and mute switch as GitHub.

An MCP server over your real test history

Point any MCP-capable client at your runs and let it answer from what actually happened, not from a guess about your codebase.

Claude Code, Cursor, Codex, or anything else that speaks MCP can ask why a suite is red, whether a test is flaky, when it started failing, and what the last run did. Setup is a read-only key and one copy-paste command from the dashboard.

Why is the suite red?
Is this test flaky?
When did it start failing?
What did the last run do?

One reporter, any CI

Add the reporter for your framework, set your project id, and every run uploads itself. There is nothing to self-host and no CI plugin to maintain.

Playwright

Full fidelity: every screenshot, video, and trace.zip uploaded and opened from the test that produced it.

@nijam/pw-reporter

pytest

A zero-dependency plugin that loads inside your pytest process and reports results, failures, and timings.

pytest-nijam

Vitest

Unit and component runs land in the same history as your end-to-end suite.

@nijam/vitest-reporter

Runs upload over HTTPS from wherever your tests already run: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, or a laptop.

Coming next

Not shipped yet, listed here so you can tell what you would be signing up for today.

Microsoft Teams

Coming soon

Run summaries in Teams channels.

Discord

Coming soon

Results in a Discord server channel.

Webhooks

Coming soon

Run events as JSON, POSTed to any HTTPS endpoint.

Connecting one takes about a minute.

Slack, GitHub, and GitLab are all OAuth. Authorize once, choose a default channel or leave the defaults, and the next run reports itself.

Free while you connect your first project · works with GitHub Actions, Jenkins, GitLab CI & CircleCI