LoginSign Up
← Back to all sparks
M

Marker.io

ANALYTICS
Velocity3.8

Marker.io stops waiting for bug reports and starts scanning sites for accessibility issues.

bug-reportingaccessibilitywebsite-monitoringmcp-integrationqa-tooling
◆Current state
Marker.io began as a widget for reporting website bugs and spent the past year adding AI to every step: translation, rewriting, title generation and an MCP server that lets coding agents fix issues from a Marker URL. In late October it launched Website Monitoring, which scans chosen pages on a schedule with 90 WCAG 2.2 AA accessibility checks and turns failures into issues.
◆Where it's heading
The product is moving from collecting problems people report to finding problems on its own, and then handing them to coding agents through MCP. Accessibility is the first monitoring check, and the release title says it is only the start. Workflow statuses and analytics fill in the team side.
◆Prediction
Expect more monitoring checks beyond accessibility, since the release frames accessibility as the first. How monitoring is priced is not clear from the entries.

◆Recent moves

  1. 18d ago

    Website Monitoring: starting with Accessibility

    ⚡ SPARK

    Marker.io moves from collecting bug reports to finding problems itself. Website Monitoring scans chosen pages on a schedule with 90 WCAG 2.2 AA accessibility checks, scores the site out of 100, assigns owners and sends issues to Jira or ClickUp, with 10 monitored pages on every plan.

  2. 8mo ago

    MCP Server - Auto resolve issues

    ⚡ SPARK

    The MCP server connects Marker to coding agents like Claude Code, letting an agent take an issue URL and auto-fix the bug, close duplicates, or sweep stale issues. This is the move that ties together the AI features Marker has been shipping — translation, title generation, rewrite — into a coherent agent-friendly pipeline. The product is no longer just collecting bugs; it is feeding them into the AI coding stack.

    View source ↗
  3. 8mo ago

    New navigation

    Workspace navigation reorganized so members and guests can discover and install the browser extension themselves, removing the admin-handholding step that gated team rollout. Widget configuration and project settings are now split into separate sections, and the empty state nudges new users into reporting a demo bug instead of installing first. The teaser line — 'room to add new products. More on that soon' — is the most interesting detail.

    View source ↗
  4. 9mo ago

    In Progress and Waiting for Approval statuses

    The issue model gets a real lifecycle: In Progress and Waiting for Approval (renameable per workflow) are added to the previously binary Open/Resolved flow, with mapping into Jira/Linear/ClickUp statuses. Archived becomes Closed, and members can change status manually even when sync is on. A long-overdue alignment with how external trackers actually work.

    View source ↗
  5. 9mo ago

    Edit field labels

    Reporters now see custom field labels on the widget without disturbing the field names that integrations depend on. Useful for translation and for hiding internal jargon from non-technical reporters. Small change, but it's the kind of polish a tool only ships once it's confident in its structural model.

    View source ↗
  6. 9mo ago

    Dynamic Variables

    Dynamic Variables let admins map reporter, browser, OS, session-replay URL, and arbitrary custom metadata to specific fields in Jira, Linear, ClickUp, etc. instead of dumping everything into the description. This is the structural prerequisite for the MCP server two months later — agents need data in fields, not buried in prose.

    View source ↗