Monitor your App

Where it lives

The second row of the App editor's Manage tab shows how your published App is doing out in the world. It has four parts:

• Traffic — who's using your App and how. Its tile shows how many people visited your Live App this week.
• Alerts — everything your App can email you about, and where you turn each one off.
• Money — what your App has cost so far this billing period, and what it has earned. Only the App's owner sees it.
• Health — what has gone wrong, and the record of what your App actually did.

These four are on every App you build. It has something to show once your App can go live — it has a web page, a backend or an action; until then each part shows one line saying what it needs, and the rest of the editor works as usual.

Each part is laid out like the rest of the editor: full-width containers, each with its name, a few short facts beside it, and its controls on the right.

Traffic and Health choose which App they show, beside the name of their first container (Visitors and Errors): All, your Live App (the one real visitors use), or your Draft (the private copy you edit against). Money covers both together and Alerts is settings, so neither has it.

Every part keeps itself up to date — the numbers refresh on their own while you're looking at them, and stop while the browser tab is in the background. The refresh icon on the first container of Traffic, Money and Health re-reads everything on that part, if you want the newest figures now.

Traffic, Money and Health are dashboards you arrange yourself. The Arrange icon on each opens its window: Layouts to stamp — Standard on all three, plus Reach and Engagement for Traffic, Speed first for Health and Sales first for Money — then its Blocks in order, each movable, removable or, for a figure of your own, changeable, and Add: a built-in block the dashboard doesn't hold yet, or a Number or chart of your own. A figure reads A list or A tracked event, counts, sums or averages it, and is drawn as a Number, Line, Bars or Ring — over time, or split by a field. The search on the Layouts reel reaches your Starred dashboards of the same kind and the Community's, the star on its Starred row stars this arrangement, and Ask AI there changes the dashboard as it stands from what you type. A rearranged dashboard reaches Live when you publish; Money's window is the owner's alone, like Money itself. An App you posted to Slop shows its Data, Money and Health as they are, with no Arrange — nothing about a posted App can be changed.

A dashboard kept on its own

A Monitor dashboard — its blocks, in order — is a setting of its own that can be kept and put into another App:

Star · Post · Copy

Traffic — who's using your App

Traffic in Manage is about people; nothing about errors lives here. How your App appears in search engines is set where it is published, on Publish in the Manage tab.

On Visitors you choose the period the numbers cover — 24h, 7d or 30d, or Dates for your own start and end. It shows your unique visitors for that period, with how many are on your App right now beside its name; that live figure ignores the period you picked. Underneath, a chart counts visitors over time, so you can see when your App gets busy.

Visitors, visits and page views are three different counts, and the wording keeps them apart: one person can visit twice and look at five pages. The headline counts people, and so does the chart under it.

Below that, Visits describes your audience — first what they did, then who they are:

• Totals — Visits, Pages per visit and Average visit: how many separate browsing sessions there were, how deep people go, and how long a visit lasts. The average counts visits where someone looked at more than one page: a single-page visit has no length to measure. Then Pages seen in all, and the share of people who Left after one page.
• Pages — which pages get the most views.
• Actions — the events your App reports itself.
• Device — the mix of phones, computers and tablets.
• Came from — where visitors were before they landed on your App.
• Region — visitors by country, when that is known.

Your own look at your Live App — the Live card on Publish, in the Manage tab — is never counted as a visitor.

Split by who was signed in

If your App has sign-in, Visits has a choice beside its name: Everyone, Signed in or Signed out. Every number and list below it follows your choice, so you can see whether people who sign in behave differently from those who don't.

Your App reports only whether someone was signed in — a plain yes or no, never who. The two halves won't always add up to Everyone: a visit from before your App reported this is genuinely unknown, so it counts toward Everyone and neither half rather than being guessed at.

There's no "returning visitors" option, and that's deliberate. Traffic is privacy-respecting: visitors are counted without storing any personal identifier, and the way that works means two different days can't be linked to the same person. Offering "returning" would mean keeping a permanent record of each individual, which is exactly what this avoids.

Choose how far back to look

Traffic in Manage only offers periods your App can actually answer. Each App keeps its history for a set number of days, so if yours keeps thirty, a ninety-day option would be sixty days of guaranteed emptiness.

To see further back, keep more. Select Dates: beside your start and end, Keep history for sets how long this App's visits, activity and errors are kept. Raising it raises how far back you can look. It is the same setting as Keep history on Health, so changing it in either place changes it everywhere. Grouped error summaries are kept three times longer, and never less than ninety days, so your error list outlives the detail behind it.

Track your own events

Beyond the built-in page views, you can count the moments that matter in your App — a sign-up, a purchase, a button click — by tracking your own events. Your App's page code calls the built-in helper:

window.mfAnalytics.track('signup', { plan: 'pro' });
window.mfAnalytics.track('buy-clicked', { item: 'ticket' });

You pass an event name and, optionally, a few plain details — never anything private about a visitor. The counts show up under Actions on Traffic in Manage, beside your most-visited pages — so you see not just how many people came, but how many did the thing you care about.

You don't have to write this yourself: ask the building assistant — "track how many people click Buy" — and it adds the tracking for you.

Health — what went wrong, and what your App did

Health in Manage is the one place something wrong shows up, in two sections.

Errors comes first: the errors your visitors actually hit, grouped so each distinct problem appears once with a count rather than as a wall of one-off messages. Each says when it was first seen and last seen, so you can tell a burst that started an hour ago from one that has run all month. Background work that failed for good lands in the same list, because a job that gave up is an error too.

Above the list you can show errors from All sources or only App code (your App's own), Connected (a service it connects to) or Platform (ours — an error marked as a MotherFluxer platform issue is not a problem with your App, and our team is notified automatically), and filter by Error or Warning. Resolve marks an error dealt with and Reopen brings it back; Show resolved includes the ones you've resolved. Press an error to open it on its details and every time it happened. The bin icon clears the errors shown, after asking in Clear errors: its lines say which Origin and Stage it clears, that Every error here, resolved ones too goes, and that Undo is Not possible. Once they are cleared, a short notice at the centre of the screen says how many error groups went. When a press like this can't go through, the reason shows at the centre of the screen until you close it or press again. Keep history sets how long visits, activity and errors are kept — the same setting as Keep history for on Traffic.

Activity comes second, and it opens with how your App is answering people for the period you pick — 1h, 24h or 7d: how many Requests it handled, its Error rate, its Typical response time and its Slowest response. Beside those, What each request got groups the answers your App sent back in plain words — every request, your own and your collaborators' page loads included —: worked, sent somewhere else, page not found, refused, or went wrong. A broken link shows up here as a run of page not found. These count requests that reached us — Cached repeat visits are not counted: your App's pages are cached for a minute at a time, so a repeat visit may not reach us. The visitor count on Traffic counts people rather than requests, so it is unaffected.

Then a Throughput chart of requests over time, and the record of what your App did, Each request on a row of its own. Select a request and its own steps open underneath it — each data read, each outbound call, each action, in order, with how long it took and what it answered. Filter the list by the kind of step and by whether it succeeded, or type into the search box: it looks through the names, the lines your App logged and the errors it recorded, so searching for an order number finds the step that mentions it.

At the bottom, By kind breaks response times down by kind of step, Background jobs counts your jobs, and By function shows each action's runs, errors, average time and last run.

Ask AI to fix an error

Any error in the Errors list on Health in Manage — except one caused by our platform, or a usage limit your App reached — has an Ask AI to fix button. A usage limit is not a fault in your code, so its note says so in place of the button: the AI can't lift a limit by editing your App. Press it and the AI reads that error, opens your App's code and tries to repair it. Nothing happens until you press: the AI never spends your credit on errors you didn't ask about.

The error then shows where the AI has got to: working on it, fixed and waiting for you to publish, or AI stopped, with the reason it couldn't finish in the error's detail — and Ask again to retry. A fix always arrives as a change to your Draft, never to your Live App, so you look at it, try it, and publish when you're happy. For an error that isn't worth fixing, open it and select Ignore.

Handing an error to the AI spends the owner's credit, so only the owner has these buttons; a collaborator sees where each error stands.

Write your own entries into the activity log

Your App can record what it MEANS, not just what the platform observed. Alongside "data write · 12ms · ok", you can log "Order #1042 confirmed" or "checkout abandoned at payment" — in your own words, in the same time-ordered trail on Health in Manage:

// Page code in your App
window.mfLog('Order confirmed', { orderId: 1042 });

// Inside one of your App's actions
ctx.log('Payment captured', { amount: 49 });

You pass a short line and, optionally, a few details. Log the business events you'd want to see when something looks wrong — not every step your code takes. Never log anything private about a visitor, and don't use it to report a problem: a real problem should be an error, so it reaches the error list and your alerts.

Logging is free and capped: if an App writes a burst of lines faster than the limit, one "logging paused" notice is recorded and the rest of that minute is skipped, so a runaway loop can't bury the trail or cost you anything. window.mfLog and ctx.log are built into every App, with nothing to turn on.

Run background jobs

Your App can do work that isn't tied to a visitor waiting on a page — send a reminder in an hour, process an uploaded file, or fan one task out into many. These are background jobs: durable work your App schedules to run later, independently of any single request.

Your App's actions schedule jobs with the built-in ctx.jobs helper, naming the action that does the work:

// run an action later — here in an hour, trying up to three times
await ctx.jobs.schedule({
  function: 'sendReminder',
  payload: { userId },
  delaySeconds: 3600,
  maxAttempts: 3,
});

// fan out — one job per item
await ctx.jobs.fanout({
  function: 'processUpload',
  payloads: uploads.map((upload) => ({ uploadId: upload.id })),
});

A job is tried once unless you ask for more attempts; with maxAttempts, it retries on failure up to that many times, so a temporary hiccup doesn't lose the work. Background jobs at the bottom of Health in Manage counts them: Pending and Running are how things stand right now — a job queued last week is still waiting today — while Done counts the period you picked, and the container says so beside its name.

You don't have to hand-write the plumbing: ask the building assistant — "send a follow-up email a day after sign-up" — and it adds the scheduled work for you.

When a background job gives up

A job that fails on every attempt it was given doesn't just vanish — it appears in the Errors list on Health in Manage, named as a background job that failed, with how many tries it had and the error that stopped it. It sits with your other errors on purpose: work that never got done is a problem you should see, not a separate list you have to remember to check.

Once you've fixed the cause — or if it was just a bad moment — select Retry to queue the job again. It also reaches you the way any other error does, so a stubborn failure can email you rather than waiting to be noticed.

Alerts — everything that can email you

Alerts in Manage lists everything your App can email you about, and where an alert can be turned off, this is where you turn it off. A limit may be set elsewhere in the editor, but whether it reaches you is decided here. Everything on this page arrives by email, and every change saves the moment you make it.

• Email to you — Send me email, the switch at the top, covering your Whole account. Turn it off and nothing below is sent, except the ones under Always sent; the containers it holds back say Email off. It is the same switch as on your account's Settings page. Only the App's owner sees it.
• Usage limits — an advisory limit on any of your App's measured resources; you're emailed once when usage passes 80% of it, and it never pauses your App.
• Errors — one row for each source of errors: App code, Connected and Platform. Switch a row on, then choose how often you hear — Every error (when a new error first appears), Daily or Weekly — and whether errors from Live, the Draft or Both send it.
• Switch-offs — a list of the moments your App stops part of itself: server features and live updates pause for the rest of the day at the platform limit, a failed build keeps your last working version live, AI answers stop at the budget you set, and a visitor is turned away at the daily limit you set with sign-in. Each is Sent as App code errors — recorded as an app error the moment it happens, so it reaches you through the App code row above, at whatever pace you set there. If you've set an AI budget, the owner also sees how much of it your Live App has used today and this month, as a bar for each.
• Always sent — a list: a web address you bought is about to expire, a deleted App left behind an address you still own, or your saved data went over the amount you pay for. These concern money or losing something you own, so they arrive Even with email off.

The Alerts buttons in the AI assistant's settings and in sign-in's settings bring you here, to the row about that limit: the limit is set where it applies, and whether it reaches you is set on this page.

When a pause lifts

A pause at a platform limit is worked out fresh from the current day's usage every time, so it lifts as soon as the day rolls over at midnight UTC — and a pause caused by stored data lifts within a few minutes of deleting enough to get back under the limit, without waiting for the day. Your App's status on Publish, in the Manage tab, says what is paused and when it clears.

One slowdown is shown rather than emailed: if your App's own server is started up again and again in a sudden burst, its scaling is slowed until midnight UTC, and your Live App's status on Publish says so. If that happens day after day, our team may hold it until someone has looked; the status then says support releases it, and contacting support is how you get it released.

Set usage alerts for your App

A published App uses resources as people use it. In Manage › Alerts, under Usage limits, you can set an advisory limit on any of these measures, so you're warned before usage climbs higher than you expected:

• CPU time — how long your actions spend running, per day.
• Outbound API calls and Outbound data — the calls your App makes to other services, and the bytes they move, per day.
• Emails sent, per day.
• Database writes, per day.
• Stored data — how much your App is holding right now.
• Database compute — for an App on its own private database, what that database uses over the period. It is listed only when your App has one.
• Requests served and Data served — how many times your published pages were fetched, and how many bytes went out, per day.

Switch a row on, type the number beside its unit, and it saves when you leave the box. Switch the row off to remove that limit.

These limits are advisory, not hard stops: when usage passes 80% of a limit, MotherFluxer emails you once for that measure and that day, and your App keeps running up to the platform's own built-in ceiling — the alert catches a runaway or an unexpectedly popular App early, it never switches it off. They apply to your published App, and only your Live App emails you — the same crossing on your Draft is recorded without mailing anyone.

Money — what your App costs, and what it earns

Money in Manage is one page with two halves: what your App has cost so far in the current billing period, and what it has taken in. Only the App's owner sees it.

If your App charges through MotherFluxer, the page opens with the two figures that answer "am I up or down" — Earned and Spent — so you don't have to add up a column to find out.

Cost this period lists one line per thing that costs money — in-app AI, a database, storage, a server, builds, and serving your App to visitors — with the total for This period. Each line shows its share of the total as a percentage, so the one actually spending your money is obvious. Some lines are charged to your credits as your App uses them; others are marked at cost, meaning we meter what your App uses without billing you separately for it; and on an App you posted to Slop, the in-app AI line is marked paid by its visitors (below). The builds line appears only if your App runs its own server: packaging that server is the one kind of build that happens on our machines rather than on your device. If your App hasn't cost anything, Cost this period says Costs nothing to run — a base App genuinely is free.

An App you posted to Slop has a Money page too, opened from its card in your Artifacts. Its visitors pay for the AI they use there, so its In-app AI line is marked paid by its visitors and left out of This period — its share reads 0% because that amount is what the post's AI cost its visitors, not what it cost you.

What you get for free lists the allowance every account has: how much you can store, how many requests and how much data your published Apps can serve in a day, and how many Apps you can build and have live on the web. These are shared across all of your Apps, and a simple App stays well inside them.

Earned this period depends on how your App charges:

• Through MotherFluxer — real figures: Sales (with how many), the MotherFluxer fee, Refunded to buyers, what You keep, what has been Paid to your bank and what is On its way to your bank, and what is Left after running costs.
• On your own Stripe account — MotherFluxer never sees that money, so no revenue figure is shown; inventing one from partial information would be worse than none. You see the customer facts we do hold, and the link icon beside Earned this period opens your Stripe dashboard for the amounts.
• Not selling anything — this half doesn't appear.

Either way that it charges, Who is paying shows your Paying customers, who was New this period and who Canceled this period, and how many customers each of your Plans has.

Through MotherFluxer, every payment counts as a sale: a one-time purchase, and a subscription's first charge and each renewal. A free trial becomes a sale when its first charge goes through.

Figures are in US dollars — what Stripe settled into your account for each sale, whatever currency the buyer paid in, so every sale is counted. A refund counts the dollars that actually left your balance.

Ask the building assistant

You never have to reach for the analytics, logging or jobs code yourself. Tell the building assistant what you want in plain language and it wires it in:

• "Track how many people click Buy."
• "Send a follow-up email a day after someone signs up."
• "Log it whenever an order is confirmed."

The results show up on Manage — Traffic for events, Health for log entries and background jobs.