Documentation

LogRabbit collects your application logs, makes them searchable, explains errors with AI, alerts you when something spikes, and watches your endpoints for downtime.

There is no SDK to install. Integration is a plain HTTPS request, so any language, framework, or runtime that can POST JSON already works — no package to add, no version to keep up to date, nothing to audit.

The API base URL is https://api.lograbbit.com.ng. Every request and response is JSON.

1. Go to Sign up and enter your first name, last name, email, and a password of at least 8 characters.
2. You are signed in straight away, and a verification email goes to the address you registered with.
3. Open that email and click the link. Until you do, the dashboard keeps you on the verification screen — you can resend the email from there if it does not arrive.

Forgot your password? Request a reset link from Forgot password. The link is valid for one hour, and using it signs out every existing session.

An organization is the billing and team boundary: it owns the plan, the subscription, and the members. You create one the first time you sign in.

A project is where logs live. Give each application or environment-group its own project — logs, alerts, monitors, and API keys are all scoped to one project and never leak across projects or organizations.

Invite teammates from Settings → Team inside a project. They receive an email invite and join your organization when they accept.

Open your project, then Settings → API Keys → Create key. Pick a scope:

• test — for local and staging traffic you do not mind mixing with experiments.
• live — for production traffic.

Keys look like pk_live_9c1f…. The full value is shown once, at creation — LogRabbit stores only a hash of it plus the first 12 characters so you can tell keys apart later. Copy it somewhere safe before closing the dialog.

Regenerate rotates a key: the replacement is issued and the old value stops working in the same operation, with no window where both are valid. Revoke kills a key outright.

Treat an API key like a password. Never commit it to source control and never put it in browser or mobile code — anything shipped to a client can be read by anyone using it. Send logs from your server.

POST to https://api.lograbbit.com.ng/v1/logs with your API key in the x-api-key header. The key identifies the project, so there is no project id in the URL.

curl -X POST https://api.lograbbit.com.ng/v1/logs \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "logs": [
      {
        "level": "info",
        "message": "User signed up",
        "environment": "production",
        "service": "auth",
        "statusCode": 200
      }
    ]
  }'

A successful call returns how many entries were stored:

{
  "accepted": 1
}

The entry shows up in the project's log explorer immediately. Here is an entry using every available field:

{
  "level": "error",
  "message": "Checkout failed: card declined",
  "environment": "production",
  "service": "payments",
  "statusCode": 402,
  "hostname": "api-worker-2",
  "requestId": "req_9f2c41",
  "userId": "user_1183",
  "timestamp": "2026-08-20T09:14:22.481Z",
  "stackTrace": "CardDeclinedError: card declined\n    at charge (payments.js:88:11)",
  "metadata": {
    "orderId": "ord_5521",
    "amountNgn": 45000,
    "gateway": "flutterwave"
  }
}

Each item in the logs array accepts these fields. Anything not listed here is rejected rather than silently dropped, so a typo fails loudly.

• Up to 500 entries per request, and up to 10 MB of JSON. Batch your writes instead of sending one request per log line.
• Up to 100 requests per minute per API key. Every response carries X-RateLimit-Remaining and X-RateLimit-Reset so you can back off before hitting it.
• Your monthly event allowance depends on your plan — see plan limits.

If a batch might be retried — a queue redelivery, a flaky network, a cron that runs twice — send an Idempotency-Key header. LogRabbit remembers that key for 24 hours per project and returns the original result instead of storing the batch a second time.

curl -X POST https://api.lograbbit.com.ng/v1/logs \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Idempotency-Key: batch-2026-08-20-0914" \
  -d '{ "logs": [{ "level": "info", "message": "Nightly job finished", "environment": "production", "statusCode": 200 }] }'

A retry that arrives while the first request is still being processed gets a 409 — wait and retry rather than dropping the key.

Ingestion returns 201 with an accepted count. Failures use a consistent shape: statusCode, message, and error, where message is an array when several fields failed validation.

{
  "statusCode": 400,
  "message": [
    "logs.0.level must be one of the following values: debug, info, warn, error, fatal",
    "logs.0.statusCode must not be less than 100"
  ],
  "error": "BadRequestException"
}

• 400 — the batch failed validation. The message names the offending index and field; nothing was stored.
• 401 — the x-api-key header is missing, revoked, or wrong.
• 402— you have used your plan's monthly event allowance. Upgrade to resume ingesting.
• 409 — a request with the same idempotency key is in flight.
• 429 — rate limited. Retry after the window in X-RateLimit-Reset.

The Logs tab in a project is the explorer. Search full text across messages and narrow down by level, environment, service, status code, request id, user id, and a time range — filters combine, and the URL keeps them so a filtered view is shareable with a teammate.

Open any entry to see its full metadata, stack trace, and the surrounding context. On paid plans you can export the current result set, or import historical logs from a file to backfill a project.

Any log entry has an Explain action: LogRabbit reads the message, status code, stack trace, and metadata and returns a plain-language account of what went wrong and where to look first.

You can also select several entries and ask for one combined explanation — useful when an incident produced a burst of related errors. Each explanation counts against your plan's monthly AI allowance.

An alert watches for a level of log — optionally narrowed to one service — and fires when it appears more than a threshold number of times inside a time window. A cooldown stops one bad deploy from paging you every minute.

Deliver to a list of email recipients, a webhook URL, or both, and assign an owner so it is clear who is looking at it. Each alert keeps a history of when it fired.

A monitor sends an HTTP request to a URL on a schedule (30 seconds or slower, with a timeout between 2 and 60 seconds) and records whether the response matched the status code you expect. Failure and recovery thresholds decide how many checks in a row it takes to flip state, so a single blip does not read as an outage.

Each project can publish a public status page from Settings → Status Page, showing your monitors' current state and recent uptime at a shareable URL your customers can check without logging in.

Logs older than your retention window are deleted automatically. See pricing for what each plan costs.

Something unclear, or an endpoint not behaving the way this page describes? Use the contact form or email hello@lograbbit.com.ng.