Error monitoring: included in every Melta product

What you get

Any product in daily use will throw an error at some point: a form that will not submit, a page that stays blank, a request that fails in the background. The question is not whether that happens but whether you see it. That is why every Melta product has a monitoring page, from its first day in the preview:

How it works

There is nothing to set up. Error monitoring is there from the first day in the preview and simply carries on once you are live. This is what it looks like from your side when something is off:

1. Take a look - Open your product's monitoring page, choose preview or live, and pick a window of 1, 6 or 24 hours. Switch to errors only to keep the list short, or to all output to see everything else your product reports.
2. Read the entry - Every error is listed with its message, stack trace and request id. If you know your way around code, you will spot the problem right away. If you do not, the next step takes care of that.
3. Have it fixed - Tell your product's chat editor what you saw, for example that registration throws an error. The editor reads the errors of the last 24 hours, tells you the cause and the affected file, and makes the change. You watch it work, can steer or interrupt it, and the preview updates as it goes.
4. Check and roll out - Test the fix in the preview and deploy it to preview or live straight from the chat. Change runs are included in every plan, so a bug fix costs you nothing extra.

The difference from an error list that sits somewhere on its own: at Melta, monitoring is wired to the tool that can also fix the error. You never have to copy a stack trace, paste it elsewhere and explain what it means. The editor has already read it.

Who this matters for

Founders with a SaaS product. If you sell subscriptions, you do not want a cancellation to be how you find out that the login has been broken since yesterday. The feed shows browser and backend errors at a glance, split into preview and live, and the chat editor fixes them with the error in front of it.

Studios with a booking system. If a class booking fails on Sunday evening, the message and its request id are still there on Monday morning, because the window reaches back up to 24 hours. The example product SOMA Yoga Zürich shows what such a product looks like.

Anyone who does not write code. You do not need to read a stack trace. Describe in the chat what you observed, and the editor explains in plain words what went wrong and in which file. The same goes for businesses with their own industry tool, such as the example product AbnahmeBlitz, where errors happen on a phone on the building site rather than at a desk.

What it costs

A concept uses only a few credits; afterwards your product runs on a plan per organisation with credits every month. All numbers and how the price is made up are on the pricing page.