On-call console.On-call console.On-call console.On-call console.

Every production team has the same story: four monitoring tools, four sets of alert emails, four different notification patterns. Someone always misses the P1. This is the on-call dashboard that fixes it.

One inbox on Inbin, 4 newsletter or alert subscriptions pointed at it. Every email that lands gets parsed against your schema.

One PUT to /v1/schemas. Inbin extracts these fields from every future email. Hallucination guard drops anything the model invented.

{
  "extract": {
    "alerts": {
      "type": "array",
      "items": {
        "severity":    { "type": "string", "nullable": true },
        "service":     { "type": "string", "required": true },
        "message":     { "type": "string", "required": true },
        "occurrences": { "type": "number", "nullable": true },
        "first_seen":  { "type": "string", "nullable": true },
        "source":      { "type": "string", "required": true }
      }
    }
  }
}

1. 01
   Create the inbox

   POST /v1/inboxes returns a permanent forwarding address like abc123@in.inbin.dev. Use it everywhere you subscribe.
2. 02
   Point the sources at it

   Enter that address directly in each source’s notification settings or signup form (Sentry, StatusPage, etc.). If a source sends a verification email, Inbin detects it and shows you the link or code to confirm. For mail that only goes to your own mailbox, a Gmail forwarding filter works as the fallback.
3. 03
   Declare the schema

   Paste the JSON above. Inbin creates version 1 and tracks every future version; any event can be re-extracted against the new shape with one call.
4. 04
   Consume the events

   Every parsed email hits your webhook as HMAC-signed JSON. Or read them via GET /v1/events. Or query them from an agent via MCP.

vs. Datadog Incident Management: $10 / host / mo.

Every product listed above exists because the underlying data was hard to get. Newsletters give you that data for free. Inbin structures it.

Also worth building