Vercel CLI permite acum căutarea trace spans dintr-un proiect direct din terminal, cu vercel traces search. Fiecare span reprezintă un pas dintr-o cerere, ceea ce ajută la investigarea erorilor, a latenței și a comportamentului legat de securitate fără a deschide dashboard-ul. Comanda returnează implicit până la 100 de span-uri din ultima oră, cele mai noi primele.

Ce s-a schimbat concret în Vercel CLI

Anunțul din changelog-ul Vercel (29.09.2026) spune clar: utilizatorii și agenții lor de cod pot căuta trace spans dintr-un proiect direct din terminal. Comanda se numește vercel traces search. Până acum, traseele de execuție erau vizibile mai ales prin dashboard, ceea ce însemna un context switching constant pentru cine lucrează în terminal sau într-un agent de cod.

Partea interesantă nu e doar căutarea în sine, ci faptul că e gândită pentru două tipuri de utilizatori simultan: omul care debughează și scriptul sau agentul care are nevoie de date structurate. Implicit, comanda întoarce până la 100 de span-uri din ultima oră, ordonate cu cele mai noi primele. Asta înseamnă că nu trebuie să cauți mai întâi un request ID sau un trace ID ca să începi investigația. Pornești de la "ce s-a întâmplat în ultima oră" și abia apoi rafinezi.

Filtrele disponibile prin opțiuni dedicate acoperă environment, service, span name, status, deployment ID, request ID, trace ID și span ID. Intervalul de timp se poate restrânge cu --since și --until. Pentru cazurile care nu au o opțiune dedicată, există --query, care acceptă un subset suportat din Kibana Query Language (KQL), cu câmpuri precum duration și atribute de span și de resursă.

Un exemplu din documentație arată căutarea span-urilor mai lente de două secunde: vercel traces search --query 'span.duration > 2000'. Altul arată filtrarea pe status de eroare cu --status error --since 1h. Iar pentru a vedea toate span-urile dintr-un singur traseu, se folosește --trace-id cu identificatorul respectiv.

Există și --json, care scoate câte un obiect JSON pe span. Acesta e probabil cel mai important detaliu pentru echipele care automatizează: datele devin consumabile de scripturi și de agenți, nu doar de ochiul uman care citește un tabel. Actualizarea se face cu vercel upgrade, iar opțiunile complete se văd cu vercel traces search --help.

De ce contează pentru debugging și pentru agenții de cod

Trace spans sunt util pentru că sparg o cerere în pași. Când ceva e lent, nu te interesează doar că răspunsul a întârziat, te interesează care pas a întârziat. Când ceva cade, nu te interesează doar codul de eroare, te interesează în ce componentă a apărut. Iar când investighezi comportament legat de securitate, vrei să vezi secvența, nu doar rezultatul final.

Faptul că această căutare ajunge în CLI schimbă fluxul de lucru. Un dezvoltator care lucrează într-un terminal poate rula o comandă și poate vedea erorile recente fără să schimbe fereastra. Un agent de cod poate primi ieșire JSON și poate decide singur ce verifică în continuare. Asta apropie debugging-ul de locul unde se scrie efectiv codul.

Pentru echipele care rulează infrastructură pe Vercel, asta reduce frecarea. Nu mai e nevoie să traduci mental între dashboard și terminal. Poți pune comanda într-un script de triaj, o poți rula la începutul unei investigații, o poți lega de un alert. În special --json face diferența între o unealtă de confort și una de automatizare.

Merită subliniat un lucru: subiectul aici e infrastructură și observabilitate, nu marketing. Nu e o funcție de reclame și nu schimbă modul în care atragi trafic. Schimbă modul în care găsești și repari problemele din spatele unui site sau ale unei aplicații. Cine administrează un magazin online sau un site de conținut simte asta indirect, prin timpul de rezolvare a unui incident, nu prin structura unei campanii.

Cum se leagă de restul stivei de observabilitate

KQL ca limbaj de interogare nu e o alegere întâmplătoare. Mulți oameni care lucrează cu loguri și trasare au deja reflexul acestei sintaxe. A o regăsi în CLI reduce curba de învățare și face tranziția dintre instrumente mai puțin dureroasă. Documentația spune explicit că Vercel suportă doar un subset din KQL, deci nu trebuie tratat ca limbaj complet.

Asta ridică o întrebare practică pentru cineva care vrea să construiască automatizări peste comandă: care câmpuri sunt stabile și care pot lipsi în funcție de tipul de span? Câmpuri precum duration apar menționate ca suportate, dar atributele de span și de resursă pot varia. Orice script care se bazează pe un câmp specific ar trebui testat pe date reale înainte de a fi pus în producție.

O altă zonă de verificat e limita implicită de 100 de span-uri din ultima oră. Pentru un proiect mic, e suficient. Pentru unul aglomerat, s-ar putea să nu acoperi tot ce te interesează, mai ales când vrei o imagine completă a unei ferestre mai lungi. Nu e clar din anunț dacă există o opțiune de a crește acest plafon sau dacă singura soluție e restrângerea filtrului. Asta e o întrebare legitimă de pus înainte de a construi un flux care se bazează pe volum.

De asemenea, securitatea datelor din span-uri rămâne un subiect de tratat cu atenție. Dacă scoți rezultate în JSON și le pasezi unui agent, trebuie să te gândești ce informație ajunge acolo. Atributele de resursă pot conține detalii care nu ar trebui să circule nestingherit prin pipeline-uri de automatizare. Regula sănătoasă rămâne aceeași: ce scoți din sistem trebuie să treacă printr-o verificare umană înainte de a deveni input pentru alt sistem.

Ce înseamnă pentru tine, ca antreprenor sau marketer în România

Dacă ai un magazin online sau un site care rulează pe Vercel și te plângi că "site-ul merge greu uneori", unealta asta îți dă un mod concret de a începe investigația. Nu îți spune singură de ce e lent, dar îți arată care pas durează. Asta scurtează discuția cu dezvoltatorul, pentru că nu mai pleci de la impresii, pleci de la o listă de span-uri filtrate.

Pentru un marketer care lucrează cu un dezvoltator extern, valoarea practică e că poți cere o verificare punctuală. În loc de "verifică site-ul, se mișcă greu", poți cere "rulează căutarea span-urilor mai lente de două secunde și spune-mi ce apare". E o diferență de maturitate operațională, nu de buget.

Există și o legătură cu ce măsurăm zilnic. Când un formular de checkout se comportă ciudat sau o pagină de produs încarcă incomplet, problema poate fi în infrastructură, nu în campanie. Aici observabilitatea tehnică se întâlnește cu conversia: dacă un pas din cerere eșuează, nici o optimizare de reclame nu salvează rezultatul. Merită privit ca pe o componentă de bază a oricărei operațiuni de e-commerce, la fel cum privești analytics-ul.

Un punct de realism: unealta nu rezolvă nimic singură. Nu îți spune ce să repari, nu prioritizează pentru tine și nu înlocuiește un om care știe sistemul. E un instrument de investigație, iar valoarea lui depinde de cine îl folosește și cât de bine înțelege arhitectura.

Ce verificăm înainte să ne bazăm pe asta

Aici e partea de disciplină. Nu luăm funcții noi ca pe niște certitudini absolute până nu le testăm în condiții reale. Pași propuși, explicit ca recomandări și nu ca rezultate măsurate:

Fiecare dintre acești pași e o ipoteză de testat, nu o concluzie. O verificare incompletă nu dovedește că o funcție lipsește sau că un element nu există. Dacă ceva nu apare într-un test, întrebarea corectă e "am testat suficient?", nu "nu funcționează".

FAQ

Ce face vercel traces search? Caută trace spans dintr-un proiect direct din terminal. Fiecare span e un pas dintr-o cerere. Comanda returnează implicit până la 100 de span-uri din ultima oră, cele mai noi primele, și permite filtrare pe environment, service, span name, status, deployment ID, request ID, trace ID sau span ID.

Pot filtra după durată? Da, prin --query cu KQL, de exemplu span.duration > 2000 pentru span-uri mai lente de două secunde. Vercel suportă doar un subset din KQL, deci nu toate expresiile sunt valide.

La ce folosește --json? Scoate câte un obiect JSON pe span. Asta face rezultatele consumabile de scripturi și de agenți, nu doar de citire umană. E opțiunea relevantă dacă vrei automatizare.

Cum actualizez CLI-ul? Cu vercel upgrade. Opțiunile complete se văd cu vercel traces search --help.

Arcul ALLSoft Agency

Uneltele de observabilitate ca asta sunt exact tipul de lucru unde AI-ul ajută concret: poate rula interogări repetitive, poate parsa ieșirea JSON și poate pregăti un rezumat al incidentelor. Dar interpretarea rămâne umană. Un media buyer sau un om tehnic știe ce înseamnă un span lent în contextul afacerii, ce merită reparat primul și ce e doar zgomot. AI-ul ajută la analiză și planning, decizia și execuția rămân la om.

Pasul concret îl face ALLSoft Agency. Dacă vrei să legi observabilitatea tehnică de măsurători care contează pentru afacere, de la performanța site-ului până la conversii, echipa te poate ajuta cu o verificare reală, fără promisiuni umflate. Detaliile de infrastructură nu sunt marketing, dar impactul lor asupra rezultatelor se vede exact în locurile în care contează.

Pentru cine lucrează cu Shopify și vrea să înțeleagă cum schimbările tehnice ajung în datele de business, merită citit și materialul despre selling_plan_id în webhook-urile de comenzi. Iar dacă te interesează partea de securitate și control la nivel de infrastructură, avem și analiza despre Cloudflare Enterprise, RBAC și Logpush.