Codeskop 推出：監察流動、網頁及後端應用程式的崩潰、錯誤和 API

A crash report tells you that something broke. It rarely tells you who it broke for, what they were doing first, or whether it is the bug that cost you customers this week.

About 2 months ago, we launched Codeskop. Codeskop is crash, error and API monitoring for mobile, web and backend apps. It connects crashes, errors, failing API calls, user journeys and releases, so your whole team sees the same production story.

Codeskop started with a simple idea we couldn't shake.

Between us, my co-founder and I have more than 16 years of building software products. We've shipped apps, built internal tools and worked on teams of every size. The best teams we worked with had one thing in common: they could see problems early and act on them together.

We wanted to give every engineering team that same advantage. Not another tool for one engineer, but one place where the whole team can see what broke, who it affected and how to fix it. That's why we built Codeskop.

This post is not a feature tour. It covers two things we think every team should know about monitoring, whichever tool you use, and then shows how to set Codeskop up in a few minutes.

1. Read impact in users, not events

Most monitoring tools show you an event count first. Event counts are loud, and loud is not the same as important.

Take two issues from the same (sample) week:

• A TimeoutException in a background sync job. 4,812 events. It looks like a fire. But it comes from 3 devices stuck in a retry loop.
• A NullPointerException in the checkout screen. 214 events. It looks quiet. But it hit 168 different people, and each of them failed to check out.

Sort by events and you fix the first one. Sort by users affected and you fix the second, which is the one costing you money.

That is why Codeskop groups crashes into issues and shows the number of users affected on each one, so the worst problems rise to the top. A "user" is the ID you pass to identify, or an anonymous install ID when nobody is signed in, so apps without login get real numbers too.

Three more questions turn a stack trace into a decision:

1. Which release? Every event carries the app version. Codeskop tracks crash-free users and sessions per release, and flags a release as regressed when crash-free users drop 0.5 points or more against the previous release (with at least 50 people on each, so a handful of early installs can't trigger it), or when a resolved issue comes back.
2. Did it fail without crashing? A 500 on POST /checkout doesn't crash anything. The user just sees a spinner and leaves. From the Starter plan, Codeskop records failed requests (a network error or an HTTP status of 400 or above) next to your crashes, with status codes and timing, so silent failures count too.
3. What did the user do first? On Growth and above, the user journey shows a person's latest session in order: the crashes, errors and failed API calls they hit and, with product analytics on, the screens and events around them. It is a timeline built from events, not a session replay. Codeskop doesn't record video, screenshots or taps.

2. Metadata, not payloads

To find a failure you need to know that a request failed, where, how slowly and for whom. You almost never need what was inside it. Request bodies hold card numbers and addresses. Query strings carry session tokens and emails. Headers carry credentials.

So Codeskop is metadata-first. The SDKs keep what you need to find and fix a failure, and redact everything else on the device, before it is queued or sent.

In practice, on Android and the web:

• Request and response bodies: never captured.
• Query strings and fragments: dropped. Only the host and path are kept.
• Authorization, Cookie and other credential headers: never captured. Only five headers are ever read: content-type, content-length, content-encoding, accept and cache-control.
• Exception messages: replaced with [REDACTED] by default, because they often contain user input. You still get the exception type and the full stack trace, and you can opt in to messages.
• Users: known only by the ID you choose. Values that look like an email address or phone number are masked.

The server SDKs follow the same rule: no bodies, cookies, Authorization headers or query strings.

Two related design choices are worth copying in your own systems:

• Write-only keys. The key in your app (cs_live_pk_…) can only send events. It can't read any data, so it is safe inside an APK or a JavaScript bundle. The SDKs refuse a secret key and simply stay switched off.
• Settings that can only reduce data. Remote config lets you pause capture (a kill-switch), toggle features and lower sampling per project without a new release. It can switch things off or lower them, never widen what is collected.

The full matrix is in the privacy docs.

Set it up in a few minutes

Create a project in the dashboard and copy its public key. Then pick your platform.

Android

Add the SDK to your app module:

dependencies {
    implementation("com.codeskop.sdk:tracker-android:0.4.0")
    // Optional: OkHttp / Retrofit network capture (recommended)
    implementation("com.codeskop.sdk:tracker-okhttp:0.4.0")
}

Then add your key to AndroidManifest.xml. The SDK starts itself, off the main thread, with no code:

<application ...>
    <meta-data
        android:name="codeskop.api_key"
        android:value="cs_live_pk_YOUR_KEY" />
</application>

Crash capture is on from the moment the SDK starts, and so is ANR detection on Starter and above. It requires minSdk 24.

Web

npm install @codeskop/tracker

import { init } from "@codeskop/tracker";

init({
  apiKey: "cs_live_pk_YOUR_KEY",
  release: "1.4.0", // optional: your app's version
});

Uncaught errors and unhandled promise rejections are captured automatically, and from Starter, so are failing fetch and XMLHttpRequest calls. There is a React package too, with a provider, an error boundary and a hook.

Python (FastAPI)

pip install codeskop

from fastapi import FastAPI
import codeskop
from codeskop.integrations.asgi import CodeskopMiddleware

codeskop.init(api_key="cs_live_pk_…")
app = FastAPI()
app.add_middleware(CodeskopMiddleware)

That gives you unhandled exceptions on every plan and, from Starter, every incoming request by route (for example /orders/{id}) and outgoing requests and httpx calls. Django, Flask and Celery have integrations as well.

The Android quick start, web quick start and server docs cover identifying users, network capture and how to send a test event.

How the pieces fit

Once events arrive, the work moves to your team:

• Alerts for new issues, spikes, regressions and slow or failing APIs. Free sends email; Starter adds Slack, WhatsApp and webhooks; Growth and above add Telegram, Discord and Microsoft Teams. A cooldown per rule means a crash loop sends one message, not hundreds.
• Tickets in Jira, Linear, GitHub Issues, Asana or ClickUp (Growth and above). You type a title; Codeskop fills in the stack trace, impact and what the user did first.
• Fix with AI (Growth and above). Your own AI provider reads the code behind the stack trace and proposes a root cause and a diff. Nothing is written until you approve, and then Codeskop opens a draft pull request on a new branch. It never merges.

Built to stay out of your app's way

A monitoring SDK should never be the reason your app breaks. The Android and web SDKs make the same promises:

• Public methods never throw, and calls made before init do nothing.
• No network or heavy disk work on the calling thread.
• Offline-first. Events are written to a queue on the device and sent in compressed batches when there is a connection. A crash on a train with no signal still reaches you.
• Crashes are never sampled or dropped for space. When the queue fills up, routine events like timings go first.
• Server SDKs never block a request. Events are batched and sent in the background, with no runtime dependencies.
• Works alongside Firebase Crashlytics. On Android, Codeskop chains onto the existing crash handler and always passes the crash along.

Platforms

• Mobile: Android (Maven Central) and Flutter (codeskop_tracker on pub.dev). Kotlin Multiplatform and iOS are in early access beta.
• Web: @codeskop/tracker and @codeskop/tracker-react on npm.
• Backend: Python, Node.js, Go, Java and PHP, plus OpenTelemetry ingest in beta for other languages.

The web and server SDKs are open source under the MIT licence on GitHub, so you can read exactly what they do before you ship them.

Pricing

There is a Free plan, with no credit card needed: 10,000 events a month, 7 days of history, 1 project and up to 5 team members, with crash and JavaScript error capture and email alerts.

Paid plans, as listed in October 2026 (USD per month, billed monthly):

Annual billing saves 15%. Enterprise and the API Trust add-on for API providers are by conversation.

Design partners

We're looking for 5 teams that ship mobile, web or backend apps where uptime and retention matter, especially in fintech and payments, e-commerce and tech. Design partners get 3 months of the Scale plan free, priority support and a shared channel with our team. In return we ask for a short case study, in your words, and permission to show your name and logo. Apply on the design partners page.

What's next

• Kotlin Multiplatform and iOS are in early access beta today.
• OpenTelemetry ingest is in beta, for other languages, for example .NET, Ruby, Rust or Elixir.
• Messaging to segments (WhatsApp, SMS and email to a group of users) is on the roadmap as a paid add-on.

Try it

Start for free on codeskop.com, add one SDK, and see your first real issue with the users it affected.

We would love your feedback, especially on the docs and the setup. Questions go to support@codeskop.com, and you can follow along on GitHub, LinkedIn and Instagram.

Olel Nashon
Founder & CTO at Codeskop.