I have my next.js app set up with the basePath option meaning that it's running on example.com/foo instead of example.com. Unfortunately, withAxiom sets up its endpoints in a way that does not seem to support basePath:

source: `${proxyPath}/web-vitals`,

where proxyPath = export const proxyPath = '/_axiom';.

I can see in the devtools' network tab that the request is being fired at example.com/_axiom/web-vitals. Would it be possible to support the basePath option so that axiom's requests would be fired at, e.g., example.com/foo/_axiom/web-vitals?

when we print logs to vercel console we receive request information with the logs. Those are missing when we send logs using axiom logger. This collects the request information and attach them as part of the fields object, they would be parsed in the backend.

I just started using Axiom and next-axiom and I'm a little lost... So any help is appreciated 👍

From the docs I found the ingest api url should be like: https://cloud.axiom.co/api/v1/datasets/$DATASET_NAME/ingest. However, I'm getting status 403, so my question is where do I need to put my API token? Just in the .env file or somewhere else?

• [X] Separate vercel, netlify and generic config handlers
• [x] ensure all variables work with vercel deployments
• [x] ensure all variables work with netlify deployments
• [x] find a way to pass auth through navigator.beacon (didn't work, beacon will only be used with verbal for now)
• [x] review namings and code structure
• [x] update README/docs for vercel and non-vercel usage
• [x] compare verbal schema before and after change
• [x] send web vitals one by one on non-vercel platforms

i'm using next-redux-wrapper to get redux store on the server side., i'm trying to console.log() the token in production to debug an issue i'm having So i'm using axiom like this

import { wrapper } from '../redux/store'
import { log } from 'next-axiom';

export const getServerSideProps = wrapper.getServerSideProps((store) => async () => {

  const token = store.getState().auth.token;
  console.log(token);
 log.info('CONSOLE.LOGGING MY TOKEN', { Type: 'YOUR TOKEN ', Token: token })
  if (token) return {
    redirect: { destination: '/dashboard', permanent: false, }
  } // Redirect to Dashboard if there is a token

  return { props: {} }
})

But i don't think i'm going about it the right way, please can you help me out

Perhaps I'm missing something obvious here, but I can't see anywhere in the docs where we can add the type declaration to the NextApiRequest type to be able to do req.log.

I’m receiving a 403 error in production (“message”: “Forbidden”) and am wondering if it’s because I didn’t add an API token.

Following your next-axiom instructions, I also added the NEXT_PUBLIC_AXIOM_INGEST_ENDPOINT to my project so that it points to a custom dataset. However, where/how do I add the corresponding API token so that the ingest endpoint can be accessed?

Since this is a custom dataset, I don’t have the Vercel integration installed via the Vercel dashboard.

My company has a NextJS web app running on Vercel, We also have a Chrome Extension version with duplicate front-end code utilizing the same api backend.

Would we be able to use the your logging functionality on both front-end implementations? (Assuming we set the correct environment variables for the Chrome extension in production)

👋

We would like to be able to send logs and web vitals from non-production Next.js deployments on Vercel.

Our use case is a canary deployment that we would like to open up to users for early feedback and testing. We would ideally receive logs and web vitals from that deployment so we can compare them with our production deployment and spot issues sooner rather than later.

Is this something you would consider supporting?

Hi! I'm new to Axiom, this looks like an awesome tool, thank you for building it!

I'm trying to set it up with Next.js and Vercel, and ran into an issue - in my production deployment, I don't see the logs printed out in the devtools console or in the function logs in Vercel's UI.

In your README it says:

When env vars are not detected, Pretty printing to console is enabled by default, to disable it set the environment variable: AXIOM_PRETTY_PRINT_ENABLED=false

My guess was that if I'd set this variable to true in production, it should enable printing the logs into the console, but it doesn't look like it's working. Even with this variable set to true, I don't see errors in my devtools.

Can you help me out? How can I enable pretty printing logs in production?

Hi there, i'm trying to set this up in a standard vercel project using the integration, and in my production deployment I get 404's on both the /logs and /web-vitals requests from my frontend.

Looks like axiom has spun up some lambdas in my project but my build output doesnt show them.

A look at the log stream for the apis shows this message: INVALID_REQUEST_METHOD: This Request was not made with an accepted method, so I guess the lambda does exist it just doesnt know how to handle a post request 🤔

What have I done wrong? I've just followed the standard setup instructions from the vercel integration page.

• Add withAxiomNextServerSidePropsHandler
• Export all withAxiom functions
• Change type signature for withAxiomNextApiHandler
• Change type signature for withAxiom

Hey, I'm building an application with the T3 stack and wanted to check if there is a better way to use Axiom with TRPC's router in a Next API route. Let me know if you see room for improvement or want more context on this.

1. Wrap the handler function in [trpc].ts with withAxiom like the docs say to.

import { createNextApiHandler } from "@trpc/server/adapters/next";
import { appRouter } from "../../../server/router";
import { createContext } from "../../../server/router/context";
import { withAxiom } from 'next-axiom'

// export API handler
export default withAxiom(
  createNextApiHandler({
    router: appRouter,
    createContext,
  })
);

2. Inside context.ts, add anisAxiomAPIRequest type guard to make sure req.log exists and confirm the request is an AxiomAPIRequest, not NextApiRequest. This will get us type safety both at compile time and runtime. Feel free to make this check more exhaustive (eg check the with function exists on log).

   Extra context: This is where the NextAPIRequest/AxiomAPIRequest is transformed into part of TRPC's own req object.

// 1 new import
import { AxiomAPIRequest } from "next-axiom/dist/withAxiom";

const isAxiomAPIRequest = (
  req?: NextApiRequest | AxiomAPIRequest
): req is AxiomAPIRequest => {
  return Boolean((req as AxiomAPIRequest)?.log);
};

export const createContext = async (
  opts?: trpcNext.CreateNextContextOptions
) => {
  const req = opts?.req;
  const res = opts?.res;

  if (!isAxiomAPIRequest(req)) {
    throw new Error("this is not the request type I expected");
  }

  const session =
    req && res && (await getServerSession(req, res, nextAuthOptions));

  const log = session ? req.log.with({ userId: session.user.id }) : req.log;

  return {
    req,
    res,
    session,
    prisma,
    log,
  };
};

3. Inside your TRPC queries and mutations, use and re-assign the logger as needed. Here, req is a TRPC request, not a NextApiResponse or AxiomAPIRequest, but we can access the logger on req.ctx.log with the expected type information.

.mutation("create-signed-url", {
  async resolve(req) {

    // add some data to all following log messages by creating a new logger using `with`
    req.ctx.log = req.ctx.log.with({ data })

    // or log a message
    req.ctx.log.info(
      'Here\'s some info', { mediaInfo }
    )
  }
})

4. Inside your main router in server/router/index.ts, add middleware to copy the reference to the newest logger back on to the AxiomAPIRequest (ctx.req) so that Axiom will flush the correct instance of the logger when the request is about to be finished.

export const appRouter = createRouter()
  .middleware(async ({ ctx, next }) => {
    const result = await next();
    (ctx.req as AxiomAPIRequest).log = ctx.log;
    return result
  })
  .merge("example.", exampleRouter)
  .merge("auth.", authRouter);

Sometimes I'm seeing a popup that looks like this:

And there's no way for me to know where this error is coming from, or what's causing this.

There should probably be a more meaningful error message that would help people understand what's going on.

But meanwhile - can you help me figure out how to find the source of the problem and fix it?