What Parsemend is

Parsemend is an error tracker that speaks the Sentry protocol, with an agent attached to it. Your SDK sends events to Parsemend instead of Sentry, the events group into issues, and the agent reads an issue, clones the linked repository, reproduces the failure, and opens a draft pull request with a fix.

Alongside errors it runs two kinds of active monitoring:

• Cron monitors watch scheduled jobs. Your job sends a check-in when it starts and when it finishes; Parsemend raises an issue when a run fails, never arrives, or runs past its time budget. That is what the rest of these docs cover.
• Uptime checks poll an HTTP endpoint on an interval and raise an issue after a configured number of consecutive failures.

Both raise ordinary issues, so everything already wired to issues (alert rules, regression detection, the agent scan) applies to them without extra setup.

How the pieces nest

Organization
└── Project              one per application or service
    ├── Keys (DSNs)      what an SDK authenticates with
    ├── Issues           grouped errors, and monitor/uptime failures
    ├── Monitors         one per scheduled job, created by its first check-in
    └── Uptime checks    one per URL you want polled

An organization is the tenant. Everything you see in the app is scoped to the organization you are currently in, and a project is the unit an SDK reports to. Most teams run one project per deployable service, because the project is what a DSN, an issue list and a monitor all hang off.

Where things live

Host	What it serves
app.parsemend.com	The panel: issues, monitors, uptime checks, alert rules, projects
account.parsemend.com	Sign in, password, two-factor, passkeys
ingest.parsemend.com	SDK ingest. This is the host baked into every DSN
api.parsemend.com	The programmatic API, and what the @parsemend/cli package talks to

The split matters for one reason: ingest.parsemend.com is a permanent contract. Every DSN handed to an SDK carries that host, and those SDKs run on machines nobody here controls, so the ingest host can never move. The panels can be reorganized freely because no deployed SDK points at them.

What to read next

• Projects, keys and DSNs to get the DSN a check-in needs.
• How monitoring works for the model behind cron monitors.
• Quickstart to send a first check-in in a few minutes.

One caveat worth setting up front: monitors are not something you create in the panel. A monitor appears the first time a check-in arrives for its slug, and its schedule comes from what the SDK sends, not from a form. If you go looking for a "New monitor" button you will not find one, by design.